Para criar um LookML eficiente, você precisa referenciar dimensões, medidas, visualizações ou tabelas derivadas existentes mesmo que elas não estejam no escopo atual. Também é necessário referenciar as colunas na tabela subjacente e usar as chamadas de função do dialeto do seu banco de dados para manipular esses valores.
Operador de substituição ($)
O operador de substituição $
torna o código do LookML mais reutilizável e modular, permitindo referenciar outras visualizações e tabelas derivadas, colunas em uma tabela SQL ou dimensões e medidas do LookML. Isso é bom por dois motivos. Primeiro, você pode já ter pensado em uma dimensão ou medida muito complicada e não precisa escrever toda a complexidade novamente. Em segundo lugar, se você alterar algo em uma dimensão ou medida, essa alteração poderá se propagar para todos os outros itens que dependem dela.
Há várias maneiras de usar o operador de substituição:
${TABLE}.column_name
faz referência a uma coluna na tabela que está conectada à visualização em que você está trabalhando. Exemplo:
dimension: customer_id {
type: number
sql: ${TABLE}.customer_id ;;
}
${field_name}
faz referência a uma dimensão ou medida na visualização em que você está trabalhando. Exemplo:
measure: total_population {
type: sum
sql: ${population} ;;
}
${view_name.field_name}
faz referência a uma dimensão ou medida a partir de outra visualização. Exemplo:
dimension: lifetime_orders {
type: number
sql: ${user_order_facts.lifetime_orders} ;;
}
${view_name.SQL_TABLE_NAME}
faz referência a outra visualização ou tabela derivada. Observe que SQL_TABLE_NAME
nesta referência é uma string literal, você não precisa substituí-la por nada. Exemplo:
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}
não funciona com o parâmetrosql_trigger
usado com grupos de dados.
Escopo e nomeação
Você pode nomear "Explorar", "Visualizações", "Campos" e "Conjuntos". Esses identificadores do Looker são escritos sem aspas.
Os campos e conjuntos do LookML têm nomes completos e nomes curtos:
- Os nomes completos têm o formato
<view>.<field-name | set-name>
. O lado esquerdo indica o escopo, que é a visualização que contém o campo ou o conjunto. O lado direito especifica o campo específico ou o nome do conjunto. - Os nomes curtos têm o formato
<field-name | set-name>
, sem ponto de separação. O Looker expande nomes curtos em nomes completos usando o escopo em que eles são usados.
Veja abaixo um exemplo que mostra muitas formas de nomes e escopo. Esse é um grupo de campos não realista, mas é mostrado para demonstrar uma variedade de possíveis expressões de escopo.
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
]
}
}
Na declaração dimension: customer_address
acima, observe que a visualização subjacente para o bloco de SQL (customer
) é diferente do escopo de visualização delimitada (orders
). Isso pode ser útil quando você precisa comparar campos entre duas visualizações diferentes.
Quando uma visualização (que chamamos de "visualização A") se refere a um campo definido em uma visualização diferente (chamada de "visualização B"), há alguns pontos a serem considerados:
- O arquivo de visualização B precisa ser incluído no mesmo modelo que a visualização A, usando o parâmetro
include
. - A visualização B precisa estar associada à visualização A em uma ou mais explorações. Consulte nossa página Como trabalhar com mesclagens no LookML para saber mais.
Dialeto SQL
O Looker é compatível com vários tipos de bancos de dados, como MySQL, Postgres, Redshift, BigQuery e outros. Cada banco de dados é compatível com um conjunto de recursos ligeiramente diferente, com diferentes nomes de função, conhecido como dialeto SQL.
O LookML foi projetado para funcionar com todos os dialetos SQL, e o LookML não prefere um dialeto ao outro. No entanto, você precisará incluir expressões de código SQL (conhecidas como blocos SQL) em determinados parâmetros do LookML. Com esses parâmetros, o Looker transmite a expressão SQL diretamente para o banco de dados. Portanto, é necessário usar o dialeto SQL correspondente ao banco de dados. Por exemplo, se você usar uma função SQL, ela precisa ser compatível com o banco de dados.
Blocos SQL
Alguns parâmetros do LookML exigem que você forneça expressões SQL brutas para que o Looker entenda como recuperar dados do seu banco de dados.
Os parâmetros LookML que começam com sql_
esperam uma expressão SQL de alguma forma. Por exemplo: sql_always_where
, sql_on
e sql_table_name
. O parâmetro LookML mais comum para blocos de SQL é sql
, usado em definições de campo de dimensão e medida para especificar a expressão SQL que define a dimensão ou medida.
O código especificado em um bloco de SQL pode ser tão simples quanto um nome de campo único ou tão complexo quanto uma subseleção correlacionada. O conteúdo pode ser bastante complexo, acomodando quase todas as necessidades que você possa ter para expressar uma lógica de consulta personalizada em SQL bruto. Observe que o código usado nos blocos SQL precisa corresponder ao dialeto SQL usado pelo banco de dados.
Exemplo de blocos SQL para dimensões e medidas
Veja abaixo exemplos de blocos SQL para dimensões e medidas. O operador de substituição LookML ($) pode fazer com que essas declarações sql
apareçam de forma enganosa ao contrário do SQL. No entanto, após a substituição, a string resultante é o SQL puro, que o Looker injeta na cláusula SELECT
da 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}) ;;
}
Conforme mostrado nas duas últimas dimensões acima, os blocos SQL podem usar funções compatíveis com o banco de dados subjacente (como as funções CONCAT
e DATEDIFF
do MySQL neste exemplo).
Exemplo de bloco SQL com uma subseleção correlacionada
É possível colocar qualquer instrução SQL no bloco SQL de um campo, incluindo uma subseleção correlacionada. Veja um exemplo abaixo:
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"
}
}
Exemplo de bloco SQL para tabelas derivadas
As tabelas derivadas usam o bloco SQL para especificar a consulta que deriva a tabela. Veja um exemplo abaixo:
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
}
}
Referências de tipo de campo LookML
Ao fazer referência a um campo LookML existente em outro campo, você pode instruir o Looker a tratar o campo referenciado como um tipo de dados específico usando dois pontos duplos (::
) seguidos pelo tipo desejado. Por exemplo, se você referenciar a dimensão orders.created_date
em outro campo, use a sintaxe ${orders.created_date::date}
para garantir que o campo created_date
seja tratado como um campo de data no SQL gerado pelo Looker, em vez de ser transmitido como uma string.
O tipo de dados que você pode usar em uma referência depende do tipo de dados do campo original ao qual você está se referindo. Por exemplo, se você referenciar um campo de string, o único tipo de dado que poderá ser especificado será ::string
. Veja a lista completa de referências a tipos de campo permitidos que você pode usar para cada tipo de campo:
- Em uma referência a um campo de string, use
::string
. - Em uma referência a um campo numérico, use
::string
e::number
. - Em uma referência a um campo de data ou hora, é possível usar
::string
,::date
e::datetime
.
As referências que usam::string
e::date
retornam dados no fuso horário da consulta, enquanto as referências que usam::datetime
retornam dados no fuso horário do banco de dados. - Em uma referência a um campo "yesno", você pode usar
::string
,::number
e::boolean
.
As referências de campo que usam o tipo::boolean
não estão disponíveis para dialetos de banco de dados que não são compatíveis com o tipo de dados booleano. - Em uma referência a um campo de local, use
::latitude
e::longitude
.
Como usar referências de tipo de campo do LookML com campos de data
Por exemplo, suponha que você tenha uma dimensão enrollment_month
e uma dimensão graduation_month
, ambas criadas em grupos de dimensão de type: time
. Neste exemplo, a dimensão enrollment_month
é produzida pelo seguinte grupo de dimensões de type: time
:
dimension_group: enrollment {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.enrollment_date ;;
}
Da mesma forma, a dimensão graduation_month
é criada pelo seguinte grupo de dimensões de type: time
:
dimension_group: graduation {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.graduation_date ;;
}
Usando as dimensões enrollment_month
e graduation_month
, você pode calcular quantos meses ou anos se passaram entre a matrícula e a graduação de um aluno criando um grupo de dimensões de type: duration
. No entanto, como alguns campos de data são convertidos como strings no SQL gerado pelo Looker, definir as dimensões enrollment_month
e graduation_month
como os valores para sql_start
e sql_end
pode resultar em um erro.
Para evitar um erro resultante do cast desses campos de tempo como strings, uma opção é criar um grupo de dimensões de type: duration
, referenciando os períodos de raw
a partir dos grupos de dimensões enrollment
e graduation
nos parâmetros sql_start
e sql_end
:
dimension_group: enrolled {
type: duration
intervals: [month, year]
sql_start: ${enrollment_raw} ;;
sql_end: ${graduation_raw} ;;
}
Na IU do Explorar, isso gera um grupo de dimensões chamado Duração da inscrição, com dimensões individuais Meses inscritos e Anos de registro.
Uma alternativa mais simples ao uso do período raw
em um grupo de dimensões de type: duration
é especificar o tipo de referência ::date
ou ::datetime
para os campos referenciados nos parâmetros sql_start
e sql_end
.
dimension_group: enrolled {
type: duration
intervals: [month, year]
sql_start: ${enrollment_month::date} ;;
sql_end: ${graduation_month::date} ;;
}
O LookML neste exemplo também cria um grupo de dimensões Duração do registro, mas o uso da referência ::date
permite que as dimensões enrollment_month
e graduation_month
sejam usadas sem usar um período de raw
ou convertê-las como strings com SQL.
Para ver um exemplo adicional de como as referências de tipo de campo do LookML podem ser usadas para criar grupos de dimensões personalizadas de type: duration
, consulte a página de documentação do parâmetro dimension_group
.
Essa sintaxe não está disponível com medidas de
type: list
, que não podem ser referenciadas a partir do Looker 6.8.
Constantes LookML
O parâmetro constant
permite especificar uma constante que pode ser usada em um projeto LookML. Com as constantes LookML, é possível definir um valor uma vez e referenciá-lo em qualquer parte do projeto em que as strings sejam aceitas, reduzindo assim a repetição no código LookML.
As constantes precisam ser declaradas em um arquivo de manifesto do projeto, e o valor de uma constante precisa ser uma string. Por exemplo, você pode definir uma city
constante com o valor "Okayama"
da seguinte maneira:
constant: city {
value: "Okayama"
}
A constante city
pode ser referenciada em todo o projeto usando a sintaxe @{city}
. Por exemplo, você pode usar a constante city
com o parâmetro label
em users
Explorar:
explore: users {
label: "@{city} Users"
}
Em seguida, o Looker exibe Usuários do Okayama no menu Explorar e no título dele, em vez da opção padrão Usuários.
Para mais informações e exemplos de como usar constantes LookML para escrever código reutilizável, consulte a página de documentação do parâmetro constant
.