Para criar um LookML eficiente, você precisa referenciar dimensões, medidas, visualizações ou tabelas derivadas atuais, mesmo que elas não estejam no escopo atual. Você também precisa fazer referência a 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 LookML mais reutilizável e modular, permitindo que você faça referência a 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ê já pode ter trabalhado com uma dimensão ou uma medida realmente complicada e não precisará escrever toda a complexidade novamente. Em segundo lugar, se você mudar algo sobre uma dimensão ou medida, essa mudança pode se propagar para todo o restante que depende 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. SQL_TABLE_NAME nesta referência é uma string literal, não é necessário 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_triggerusado com datagroups.
Escopo e nomeação
Você pode nomear o recurso "Explorar", "Visualizações", "Campos" e "Conjuntos". Os identificadores do Looker são escritos sem aspas.
Os campos e conjuntos do LookML têm nomes completos e nomes curtos:
- Os nomes completos estão no 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 separação. O Looker expande os nomes curtos para nomes completos usando o escopo em que 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 diversas expressões de escopo possíveis.
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, a visualização subjacente do bloco SQL (customer) é diferente do escopo de visualização delimitada (orders). Isso pode ser útil quando você precisar comparar campos entre duas visualizações diferentes.
Quando uma visualização (que vamos chamar de "quot;view A"") se refere a um campo definido em uma visualização diferente (nós vamos chamá-la de "quot;view B""), há alguns itens 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 ser mesclada para a visualização A em uma ou mais explorações. Consulte nossa página Como trabalhar com mesclagens no LookML para saber mais sobre mesclagens.
Dialeto SQL
O Looker oferece suporte a vários tipos de bancos de dados, como MySQL, Postgres, Redshift, BigQuery e assim por diante. Cada banco de dados é compatível com um conjunto de atributos ligeiramente diferente, com diferentes nomes de função, chamados de dialeto SQL.
O LookML foi projetado para funcionar com todos os dialetos SQL, e o LookML não prefere um dialeto em vez de outro. No entanto, será necessário incluir expressões de código SQL (conhecidas como blocos SQL) em determinados parâmetros LookML. Com esses parâmetros, o Looker transmite a expressão SQL diretamente para seu banco de dados, portanto, é necessário usar o dialeto SQL que corresponda ao seu banco de dados. Por exemplo, se você usar uma função SQL, ela precisa ser uma função 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 possa entender como recuperar dados do seu banco de dados.
Os parâmetros LookML iniciados por sql_ esperam uma expressão SQL de algum formato. 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 do SQL pode ser tão simples quanto um único nome de campo ou tão complexo quanto uma subseleção correlacionada. O conteúdo pode ser bastante complexo e acomodar quase todas as suas necessidades de expressar a 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 bloqueios de SQL para dimensões e medidas
Veja abaixo exemplos de bloqueios de 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, diferente do SQL. No entanto, após a substituição, a string resultante é 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.
Exemplo de bloco SQL com uma subseleção correlacionada
É possível colocar qualquer instrução SQL em um bloco do SQL do 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 tipos de campos do LookML
Ao referenciar um campo LookML atual em outro campo, é possível instruir o Looker para que ele trate 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, poderá usar 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 referenciado. Por exemplo, se você está fazendo referência a um campo de string, o único tipo de dado que você pode especificar é ::string. Veja a lista completa de referências de tipo de campo permitidas 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 de número, use
::stringe::number. - Em uma referência a um campo de data ou hora, é possível usar
::string,::datee::datetime.
As referências que usam::stringe::dateretornam dados no fuso horário da consulta, enquanto as referências que usam::datetimeretornam dados no fuso horário do banco de dados. - Em uma referência a um campo "yesno", você pode usar
::string,::numbere::boolean.
Referências de campo que usam o tipo::booleannão estão disponíveis para dialetos de bancos de dados incompatíveis com o tipo de dados booleanos. - Em uma referência a um campo de local, use
::latitudee::longitude.
Como usar referências de tipo de campo LookML com campos de data
Por exemplo, imagine que você tenha uma dimensão enrollment_month e uma dimensão graduation_month, e ambas foram criadas em grupos de dimensões 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 da 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 passou entre a inscrição 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 de sql_start e sql_end pode resultar em um erro.
Para evitar que um erro resultante da transmissão desses campos de tempo seja uma string, uma opção é criar um grupo de dimensões de type: duration, fazendo referência aos 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 da ferramenta Explorar, um grupo de dimensões chamado Duração do registro é gerado, com as dimensões individuais Meses inscritos e Ano de registro.
Uma alternativa mais simples ao uso do período raw em um grupo de dimensões da 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. No entanto, usar a referência ::date permite que as dimensões enrollment_month e graduation_month sejam usadas sem usar um período raw ou convertê-las como strings com SQL.
Para ver outro exemplo de como as referências de tipo de campo LookML podem ser usadas para criar grupos de dimensões personalizadas de type: duration, consulte a página de documentação de parâmetros 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 de 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 são aceitas, reduzindo 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 constante city com o valor "Okayama" da seguinte maneira:
constant: city {
value: "Okayama"
}
A constante city pode então ser referenciada em todo o projeto usando a sintaxe @{city}. Por exemplo, é possível usar a constante city com o parâmetro label em users Explore:
explore: users {
label: "@{city} Users"
}
Em seguida, o Looker mostra Usuários do Okayama no menu Explorar e no título do Explorar, em vez do Usuários padrão.
Para mais informações e exemplos de como usar constantes LookML para escrever códigos reutilizáveis, consulte a página de documentação de parâmetros constant.