Para escribir LookML eficaz, debe poder hacer referencia a dimensiones, medidas, vistas o tablas derivadas aunque no estén en el ámbito actual. También debe hacer referencia a las columnas de la tabla subyacente y usar las llamadas a funciones del dialecto de su base de datos para manipular esos valores.
Operador de sustitución ($)
El operador de sustitución, $, hace que el código LookML sea más reutilizable y modular, lo que te permite hacer referencia a otras vistas y tablas derivadas, columnas de una tabla SQL o dimensiones y medidas de LookML. Esto es bueno por dos motivos. En primer lugar, es posible que ya hayas calculado una dimensión o una métrica muy complejas, por lo que no tendrás que volver a escribir toda la complejidad. En segundo lugar, si cambia algo de una dimensión o una métrica, ese cambio puede propagarse a todo lo demás que dependa de ella.
Puedes usar el operador de sustitución de varias formas:
${TABLE}.column_name hace referencia a una columna de la tabla 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 una medida 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 una medida de 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 a una tabla derivada. Ten en cuenta que SQL_TABLE_NAME en esta referencia es una cadena literal, por lo que no tienes que sustituirla 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ámetrosql_triggerque se usa con datagroups.
Ámbito y nomenclatura
Puedes asignar nombres a las exploraciones, las vistas, los campos y los conjuntos. Estos identificadores de Looker se escriben sin comillas.
Los campos y los conjuntos de LookML tienen nombres completos y nombres abreviados:
- Los nombres completos tienen el formato
<view>.<field-name | set-name>. En la parte izquierda se indica el ámbito, que es la vista que contiene el campo o el conjunto. En la parte derecha se especifica el campo o el nombre del conjunto en concreto. - Los nombres cortos tienen el formato
<field-name | set-name>, sin puntos que los separen. Looker amplía los nombres cortos a nombres completos mediante el ámbito en el que se utilizan.
A continuación, se muestra un ejemplo con muchas formas de nombres y ámbitos. Se trata de un grupo de campos poco realista, pero se muestra para demostrar una variedad de expresiones de ámbito 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, ten en cuenta que la vista subyacente del bloque SQL (customer) es diferente del ámbito de la vista envolvente (orders). Esto puede ser útil cuando necesites comparar campos entre dos vistas diferentes.
Cuando una vista (a la que llamaremos "vista A") hace referencia a un campo definido en otra vista (a la que llamaremos "vista B"), hay algunas cosas que debes tener en cuenta:
- El archivo de la vista B debe incluirse en el mismo modelo que la vista A mediante el parámetro
include. - La vista B debe combinarse con la vista A en una o varias exploraciones. Consulta nuestra página Trabajar con combinaciones en LookML para obtener información sobre las combinaciones.
Dialecto SQL
Looker admite muchos tipos de bases de datos, como MySQL, Postgres, Redshift, BigQuery, etc. Cada base de datos admite un conjunto de funciones ligeramente diferente con nombres de funciones distintos, lo que se conoce como dialecto SQL.
LookML se ha diseñado para funcionar con todos los dialectos de SQL y no prefiere un dialecto sobre otro. Sin embargo, tendrás que incluir expresiones de código SQL (conocidas como bloques de SQL) en determinados parámetros de LookML. Con estos parámetros, Looker transfiere la expresión SQL directamente a tu base de datos, por lo que debes usar el dialecto de SQL que coincida con tu base de datos. Por ejemplo, si usas una función SQL, debe ser una función que admita tu base de datos.
Bloques de SQL
Algunos parámetros de LookML requieren que proporciones expresiones SQL sin formato para que Looker pueda entender cómo obtener datos de tu base de datos.
Los parámetros de LookML que empiezan por sql_ esperan una expresión SQL de algún tipo. Por ejemplo: sql_always_where, sql_on y sql_table_name. El parámetro de LookML más habitual para los bloques de SQL es sql, que se usa en las definiciones de campos de dimensión y medida para especificar la expresión de SQL que define la dimensión o la medida.
El código que especifiques en un bloque SQL puede ser tan sencillo como un solo nombre de campo o tan complejo como una subconsulta correlacionada. El contenido puede ser bastante complejo y adaptarse a casi cualquier necesidad que tengas para expresar la lógica de consulta personalizada en SQL sin formato. Ten en cuenta que el código que uses en los bloques de SQL debe coincidir con el dialecto SQL que utilice la base de datos.
Ejemplos de bloques de SQL para dimensiones y métricas
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ñosamente diferentes a SQL. Sin embargo, una vez que se ha producido la sustitución, la cadena 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, 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 SQL con una subconsulta correlacionada
Puedes colocar cualquier instrucción SQL en el bloque SQL de un campo, incluida una subconsulta 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"
}
}
Bloque de SQL de ejemplo para tablas derivadas
Las tablas derivadas usan el bloque 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 haces referencia a un campo de LookML en otro campo, puedes indicar a Looker que trate el campo al que se hace referencia como un tipo de datos específico usando dos puntos (::) seguidos del tipo que quieras. Por ejemplo, si haces referencia a la dimensión orders.created_date en 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 convertirse en una cadena.
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 cadena, el único tipo de datos que puedes especificar es ::string. A continuación, se muestra la lista completa de referencias de tipos de campos permitidas que puede usar para cada tipo de campo:
- En una referencia a un campo de cadena, puedes usar
::string. - En una referencia a un campo numérico, puedes usar
::stringy::number. - En una referencia a un campo de fecha u hora, puedes usar
::string,::datey::datetime.Las referencias que usan::stringy::datedevuelven datos en la zona horaria de la consulta, mientras que las referencias que usan::datetimedevuelven datos en la zona horaria de la base de datos. - En una referencia a un campo sí/no, puedes usar
::string,::numbery::boolean. Las referencias de campo que usan el tipo::booleanno están disponibles en dialectos de bases de datos que no admiten el tipo de datos booleano. - En una referencia a un campo de ubicación, puedes usar
::latitudey::longitude.
Usar referencias de tipo de campo de LookML con campos de fecha
Por ejemplo, supongamos que tiene una dimensión enrollment_month y una dimensión graduation_month, ambas creadas en grupos de dimensiones de type: time. En este ejemplo, la dimensión enrollment_month se genera a partir del siguiente grupo de dimensiones de type: time:
dimension_group: enrollment {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.enrollment_date ;;
}
Del mismo modo, la dimensión graduation_month se crea a partir del 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 han transcurrido entre la inscripción y la graduación de un alumno creando un grupo de dimensiones de type: duration. Sin embargo, como algunos campos de fecha se convierten en cadenas en el SQL que genera Looker, si se definen las dimensiones enrollment_month y graduation_month como valores de sql_start y sql_end, se puede producir un error.
Para evitar que se produzca un error al convertir estos campos de tiempo en cadenas, una opción es crear un grupo de dimensiones de type: duration que haga referencia a los periodos 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 interfaz de Explorar, se genera un grupo de dimensiones llamado Tiempo de registro, con las dimensiones Meses de registro y Años de registro.
Una alternativa más sencilla a usar el periodo 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} ;;
}
El LookML de este ejemplo también crea un grupo de dimensiones Tiempo de registro, pero el uso de la referencia ::date permite usar las dimensiones enrollment_month y graduation_month sin usar un periodo raw ni convertirlas en cadenas con SQL.
Para ver otro ejemplo de cómo se pueden usar las referencias de tipo de campo de 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 las medidas de
type: list, a las que no se puede hacer referencia desde Looker 6.8.
Constantes de LookML
El parámetro constant te permite especificar una constante que puedes usar en todo un proyecto de LookML. Con las constantes de LookML, puede definir un valor una vez y hacer referencia a él en cualquier parte de su proyecto en la que se acepten cadenas. De esta forma, se reduce la repetición en el código LookML.
Las constantes deben declararse en un archivo de manifiesto del proyecto y su valor debe ser una cadena. Por ejemplo, puedes definir una constante city con el valor "Okayama" de la siguiente manera:
constant: city {
value: "Okayama"
}
La constante city se puede consultar en todo el proyecto con la sintaxis @{city}. Por ejemplo, puede usar la constante city con el parámetro label en la sección users Explorar:
explore: users {
label: "@{city} Users"
}
A continuación, Looker muestra Usuarios de Okayama tanto en el menú Explorar como en el título de la exploración, en lugar de Usuarios, que es el valor predeterminado.
Para obtener más información y ejemplos de cómo puedes usar constantes de LookML para escribir código reutilizable, consulta la página de documentación del parámetro constant.