Ten en cuenta que estás viendo la documentación de Looker. Para obtener documentación de Looker Studio, visita https://support.google.com/looker-studio.

Incorporar SQL y hacer referencia a objetos LookML

Para escribir recursos potentes de LookML, es necesario poder hacer referencia a las dimensiones, medidas, vistas o tablas derivadas existentes, incluso si no están dentro del alcance actual. También debes hacer referencia a las columnas de la tabla subyacente y usar las llamadas a funciones del dialecto de tu base de datos para manipular esos valores.

Operador de sustitución ($)

El operador de sustitución, $, hace que el código de LookML sea más reutilizable y modular, lo que te permite hacer referencia a otras vistas y tablas derivadas, columnas de una tabla de SQL o dimensiones y medidas de LookML. Esto es bueno por dos motivos. En primer lugar, es posible que ya hayan elaborado una dimensión o medición realmente complicadas, por lo que no es necesario volver a escribir toda la complejidad. En segundo lugar, si cambia algo sobre una dimensión o medición, ese cambio puede propagarse a todo lo demás que se base en ella.

Existen varias formas de usar el operador de sustitución:

${TABLE}.column_name hace referencia a una columna de la tabla que está conectada a la vista en la que estás trabajando. Por ejemplo:

dimension: customer_id {
  type: number
  sql: ${TABLE}.customer_id ;;
}

${field_name} hace referencia a una dimensión o medición dentro de la vista en la que estás trabajando. Por ejemplo:

measure: total_population {
  type: sum
  sql: ${population} ;;
}

${view_name.field_name} hace referencia a una dimensión o medición desde otra vista. Por ejemplo:

dimension: lifetime_orders {
  type: number
  sql: ${user_order_facts.lifetime_orders} ;;
}

${view_name.SQL_TABLE_NAME} hace referencia a otra vista o tabla derivada. Ten en cuenta que SQL_TABLE_NAME en esta referencia es una string literal; no necesitas reemplazarla por nada. Por ejemplo:

explore: trips {
  view_label: "Long Trips"
  # This will ensure that we only see trips that are longer than average!
  sql_always_where: ${trips.trip_duration}>=(SELECT tripduration FROM ${average_trip_duration.SQL_TABLE_NAME});;
}

${view_name.SQL_TABLE_NAME} no funciona con el parámetro sql_trigger que se usa con los grupos de datos.

Alcance y nombres

Puedes nombrar Exploraciones, vistas, campos y conjuntos. Estos identificadores de Looker están escritos sin comillas.

Los campos y conjuntos de LookML tienen nombres completos y nombres cortos:

Los nombres completos tienen el formato <view>.<field-name | set-name>. El lado izquierdo indica el alcance, que es la vista que contiene el campo o el conjunto. En el lado derecho, se especifica el campo o nombre del conjunto particular.
Los nombres cortos solo tienen el formato <field-name | set-name>, sin punto separador. Looker expande los nombres cortos a los nombres completos mediante el alcance en que se usan.

A continuación, se muestra un ejemplo en el que se muestran muchas formas de nombres y alcance. Este es un grupo de campos poco realista, pero se muestra para demostrar una variedad de expresiones de alcance posibles.

view: orders {                   # "orders" becomes the containing scope
  measure: count {               # short name, equivalent to orders.count
    type: count
  }
  dimension: customer_id {       # short name, equivalent to orders.customer_id
    type: number
    sql: ${TABLE}.customer_id ;;
  }
  dimension: customer_address {  # short name, equivalent to orders.customer_address
    sql: ${customer.address} ;;  # full name, references a field defined in the "customer" view
  }
  set: drill_fields {            # short name, equivalent to orders.drill_fields
    fields: [
      count,                     # short name, equivalent to orders.count
      customer.id                # full name, references a field defined in the "customer" view
    ]
  }
}

En la declaración dimension: customer_address anterior, ten en cuenta que la vista subyacente del bloque de SQL (customer) es diferente del permiso de la vista de cierre (orders). Esto puede ser útil cuando necesitas comparar campos entre dos vistas diferentes.

Cuando una vista (a la que llamaremos "vista A") se refiere a un campo definido en una vista diferente (que la llamaremos "vista B"), hay que tener en cuenta lo siguiente:

El archivo de vista B debe incluirse en el mismo modelo que la vista A, con el parámetro include.
La vista B debe estar unida para ver A en una o más exploraciones. Consulte la página Cómo trabajar con uniones en LookML para obtener información sobre estas.

Dialecto de SQL

Looker admite muchos tipos de bases de datos, como MySQL, Postgres, Redshift, BigQuery, etcétera. Cada base de datos admite un conjunto de atributos un poco diferente con diferentes nombres de funciones, denominado dialecto SQL.

LookML está diseñado para funcionar con todos los dialectos de SQL, y LookML no prefiere un dialecto por sobre el otro. Sin embargo, deberá incluir expresiones de código SQL (conocidas como bloques de SQL) en ciertos parámetros de LookML. Con estos parámetros, Looker pasa la expresión de SQL directamente a su base de datos, por lo que debe usar el dialecto de SQL que coincida con esta. Por ejemplo, si usas una función de SQL, debe ser compatible con tu base de datos.

Bloques de SQL

Algunos parámetros de LookML requieren que proporciones expresiones SQL sin procesar para que Looker comprenda cómo recuperar datos de tu base de datos.

Los parámetros de LookML que comienzan con sql_ esperan una expresión de SQL de alguna forma. Estos son algunos ejemplos: sql_always_where, sql_on y sql_table_name. El parámetro más común de LookML para bloques de SQL es sql, que se usa en las definiciones de campos de dimensiones y mediciones a fin de especificar la expresión de SQL que define la dimensión o la medida.

El código que especifique en un bloque de SQL puede ser tan simple como un solo nombre de campo o tan complejo como una subselección correlacionada. El contenido puede ser bastante complejo y contempla casi cualquier necesidad que tengas para expresar una lógica de consulta personalizada en SQL sin procesar. Ten en cuenta que el código que usas en los bloques de SQL debe coincidir con el dialecto de SQL que usa la base de datos.

Ejemplo de bloques de SQL para dimensiones y medidas

A continuación, se muestran ejemplos de bloques de SQL para dimensiones y medidas. El operador de sustitución de LookML ($) puede hacer que estas declaraciones de sql parezcan engañosas a diferencia de SQL. Sin embargo, después de que se realice la sustitución, la string resultante es SQL puro, que Looker inserta en la cláusula SELECT de la consulta.

dimension: id {
  primary_key: yes
  sql: ${TABLE}.id ;;   # Specify the primary key, id
}
measure: average_cost {
  type: average
  value_format: "0.00"
  sql: ${order_items.cost} ;;   # Specify the field that you want to average
}
dimension: name {
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}
dimension: days_in_inventory {
  type: int
  sql: DATEDIFF(${sold_date}, ${created_date}) ;;
}

Como se muestra en las dos últimas dimensiones anteriores, los bloques de SQL pueden usar funciones compatibles con la base de datos subyacente (como las funciones CONCAT y DATEDIFF de MySQL en este ejemplo).

Ejemplo de bloque de SQL con una subselección correlacionada

Puede colocar cualquier instrucción de SQL en el bloque de SQL de un campo, incluida una subselección correlacionada. A continuación, se muestra un ejemplo:

view: customers {
  dimension: id {
    primary_key: yes
    sql: ${TABLE}.id ;;
  }
  dimension: first_order_id {
    sql: (SELECT MIN(id) FROM orders o WHERE o.customer_id=customers.id) ;;
         # correlated subselect to derive the value for "first_order_id"
  }
}

Ejemplo de bloque de SQL para tablas derivadas

Las tablas derivadas usan el bloque de SQL para especificar la consulta que deriva la tabla. A continuación, se muestra un ejemplo:

view: user_order_facts {
  derived_table: {
    sql:            # Get the number of orders for each user
      SELECT
        user_id
        , COUNT(*) as lifetime_orders
      FROM orders
      GROUP BY 1 ;;
  }
  # later, dimension declarations reference the derived column(s)

  dimension: lifetime_orders {
    type: number
  }
}

Referencias de tipos de campos de LookML

Cuando hagas referencia a un campo existente de LookML dentro de otro campo, puedes indicarle a Looker que trate el campo al que se hace referencia como un tipo de datos específico mediante dos puntos seguidos (::) del tipo deseado. Por ejemplo, si haces referencia a la dimensión orders.created_date dentro de otro campo, puedes usar la sintaxis ${orders.created_date::date} para asegurarte de que el campo created_date se trate como un campo de fecha en el SQL que genera Looker, en lugar de transmitirse como una string.

El tipo de datos que puedes usar en una referencia depende del tipo de datos del campo original al que haces referencia. Por ejemplo, si haces referencia a un campo de string, el único tipo de datos que puedes especificar es ::string. Esta es la lista completa de referencias de tipo de campo permitidas que puedes usar para cada tipo de campo:

En una referencia a un campo de string, puedes usar ::string.
En una referencia a un campo de número, puedes usar ::string y ::number.
En una referencia a un campo de fecha o de hora, puedes usar ::string, ::date y ::datetime.
Las referencias que usan ::string y ::date muestran datos en la zona horaria de la consulta, mientras que las referencias que usan ::datetime muestran datos en la zona horaria de la base de datos.
En una referencia a un campo sí, puedes usar ::string, ::number y ::boolean.
Las referencias de campo que usan el tipo ::boolean no están disponibles para los dialectos de la base de datos que no admiten el tipo de datos booleano.
En una referencia a un campo de ubicación, puedes usar ::latitude y ::longitude.

Usa referencias de tipo de campo LookML con campos de fecha

A modo de ejemplo, supongamos que tienes una dimensión de enrollment_month y una de graduation_month, que se crearon dentro de grupos de dimensiones de type: time. En este ejemplo, el siguiente grupo de dimensiones de type: time produce la dimensión enrollment_month:


dimension_group: enrollment {
  type: time
  timeframes: [time, date, week, month, year, raw]
  sql: ${TABLE}.enrollment_date ;;
}

Del mismo modo, se crea la dimensión graduation_month con el siguiente grupo de dimensiones de type: time:


dimension_group: graduation {
  type: time
  timeframes: [time, date, week, month, year, raw]
  sql: ${TABLE}.graduation_date ;;
}

Con las dimensiones enrollment_month y graduation_month, puedes calcular cuántos meses o años pasaron entre la inscripción y la graduación de un alumno mediante la creación de un grupo de dimensiones de type: duration. Sin embargo, debido a que algunos campos de fecha se convierten en strings en el SQL que genera Looker, la configuración de las dimensiones enrollment_month y graduation_month como los valores para sql_start y sql_end puede generar un error.

Para evitar que se produzca un error cuando estos campos de tiempo se convierten en strings, puedes crear un grupo de dimensiones de type: duration y hacer referencia a los períodos de tiempo raw de los grupos de dimensiones enrollment y graduation en los parámetros sql_start y sql_end:


dimension_group: enrolled {
  type: duration
  intervals: [month, year]
  sql_start: ${enrollment_raw} ;;
  sql_end: ${graduation_raw} ;;
}

En la IU de Explorar, esto genera un grupo de dimensiones llamado Duración inscrita, con dimensiones individuales Meses inscritos y Años inscritos.

Una alternativa más sencilla a usar el período raw en un grupo de dimensiones de type: duration es especificar el tipo de referencia ::date o ::datetime para los campos a los que se hace referencia en los parámetros sql_start y sql_end.


dimension_group: enrolled {
  type: duration
  intervals: [month, year]
  sql_start: ${enrollment_month::date} ;;
  sql_end: ${graduation_month::date} ;;
}

En este ejemplo, LookML también crea un grupo de dimensiones Duración inscrita, pero el uso de la referencia ::date permite que se usen las dimensiones enrollment_month y graduation_month sin utilizar un período de raw ni transmitirlas como strings con SQL.

Si quieres obtener un ejemplo adicional de cómo se pueden usar las referencias de tipo de campo LookML para crear grupos de dimensiones personalizadas de type: duration, consulta la página de documentación del parámetro dimension_group.

Esta sintaxis no está disponible con medidas de type: list, a las que no se puede hacer referencia a partir de Looker 6.8.

Constantes de LookML

El parámetro constant te permite especificar una constante que puedes usar en un proyecto de LookML. Con las constantes de LookML, puedes definir un valor una vez y hacer referencia a él en cualquier parte de tu proyecto donde se acepten strings, lo que reduce la repetición en tu código de LookML.

Se deben declarar las constantes dentro de un archivo de manifiesto del proyecto, y el valor de una constante debe ser una string. Por ejemplo, puedes definir una constante city con el valor "Okayama" de la siguiente manera:

constant: city {
  value: "Okayama"
}

Luego, se puede hacer referencia a la constante city en tu proyecto mediante la sintaxis @{city}. Por ejemplo, puedes usar la constante city con el parámetro label en la sección users Explorar:


explore: users {
  label: "@{city} Users"
}

Luego, Looker muestra Usuarios de Okayama en el menú Explorar y en el título del elemento, en lugar de hacerlo en los Usuarios predeterminados.

Si quieres obtener más información y ejemplos de cómo puedes usar las constantes de LookML para escribir código reutilizable, consulta la página de documentación del parámetro constant.