Esta página foi traduzida pela API Cloud Translation.

Incorporar SQL e referir-se a objetos do LookML

Para escrever um LookML eficaz, tem de poder fazer referência a dimensões, medidas, vistas ou tabelas derivadas existentes, mesmo que não estejam no âmbito atual. Também tem de fazer referência a colunas na tabela subjacente e usar as chamadas de funções do dialeto da base 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, o que lhe permite fazer referência a outras vistas e tabelas derivadas, colunas numa tabela SQL ou dimensões e medidas do LookML. Isto é bom por dois motivos. Primeiro, pode já ter resolvido uma dimensão ou uma medida realmente complexa e não precisa de escrever novamente toda a complexidade. Em segundo lugar, se alterar algo numa dimensão ou numa medida, essa alteração pode propagar-se a tudo o resto que dependa dela.

Existem várias formas de usar o operador de substituição:

${TABLE}.column_name faz referência a uma coluna na tabela associada à vista na qual está a trabalhar. Por exemplo:

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

${field_name} faz referência a uma dimensão ou uma medida na vista em que está a trabalhar. Por exemplo:

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

${view_name.field_name} faz referência a uma dimensão ou uma medida de outra vista. Por exemplo:

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

${view_name.SQL_TABLE_NAME} faz referência a outra vista ou a uma tabela derivada. Tenha em atenção que SQL_TABLE_NAME nesta referência é uma string literal e não tem de a substituir por nada. Por 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âmetro sql_trigger usado com datagroups.

Âmbito e nomenclatura

Pode atribuir nomes a explorações, vistas, campos e conjuntos. Estes identificadores do Looker são escritos sem aspas.

Os campos e os conjuntos do LookML têm nomes completos e nomes abreviados:

Os nomes completos têm o formato <view>.<field-name | set-name>. O lado esquerdo indica o âmbito, que é a vista que contém o campo ou o conjunto. O lado direito especifica o campo ou o nome do conjunto específico.
Os diminutivos têm simplesmente o formato <field-name | set-name>, sem ponto de separação. O Looker expande os nomes abreviados em nomes completos através do âmbito em que são usados.

Segue-se um exemplo que mostra muitas formas de nomes e âmbito. Este é um grupo de campos irrealista, mas é apresentado para demonstrar uma variedade de possíveis expressões de âmbito.

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, repare que a vista subjacente do bloco SQL (customer) é diferente do âmbito da vista de inclusão (orders). Isto pode ser útil quando precisa de comparar campos entre duas vistas diferentes.

Quando uma visualização (a que chamaremos "visualização A") se refere a um campo definido numa visualização diferente (a que chamaremos "visualização B"), há alguns aspetos a ter em conta:

O ficheiro da vista B tem de ser incluído no mesmo modelo que a vista A, através do parâmetro include.
A vista B tem de ser unida à vista A num ou mais Explorar. Consulte a nossa página Trabalhar com junções no LookML para saber mais sobre as junções.

Dialeto SQL

O Looker suporta muitos tipos de bases de dados, como MySQL, Postgres, Redshift, BigQuery, etc. Cada base de dados suporta um conjunto de funcionalidades ligeiramente diferente com nomes de funções diferentes, denominado dialeto SQL.

O LookML foi concebido para funcionar com todos os dialetos de SQL e não prefere um dialeto em detrimento de outro. No entanto, tem de incluir expressões de código SQL (conhecidas como blocos SQL) em determinados parâmetros LookML. Com estes parâmetros, o Looker transmite a expressão SQL diretamente para a sua base de dados, pelo que tem de usar o dialeto SQL que corresponde à sua base de dados. Por exemplo, se usar uma função SQL, tem de ser uma função suportada pela sua base de dados.

Blocos SQL

Alguns parâmetros do LookML requerem que forneça expressões SQL não processadas para que o Looker possa compreender como obter dados da sua base de dados.

Os parâmetros do LookML que começam por sql_ esperam uma expressão SQL de alguma forma. Exemplos: sql_always_where, sql_on e sql_table_name. O parâmetro LookML mais comum para blocos SQL é sql, usado nas definições de campos de dimensões e medidas para especificar a expressão SQL que define a dimensão ou a medida.

O código que especifica num bloco SQL pode ser tão simples como o nome de um único campo ou tão complexo como uma subseleção correlacionada. O conteúdo pode ser bastante complexo, acomodando quase todas as necessidades que possa ter para expressar a lógica de consulta personalizada em SQL não processado. Tenha em atenção que o código que usa nos blocos SQL tem de corresponder ao dialeto de SQL usado pela base de dados.

Exemplos de blocos SQL para dimensões e medidas

Seguem-se exemplos de blocos SQL para dimensões e medidas. O operador de substituição do LookML ($) pode fazer com que estas declarações sql pareçam enganadoramente diferentes do SQL. No entanto, depois de ocorrer 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, os blocos SQL podem usar funções suportadas pela base de dados subjacente (como as funções CONCAT e DATEDIFF do MySQL neste exemplo).

Exemplo de um bloco de SQL com uma subseleção correlacionada

Pode colocar qualquer declaração SQL no bloco SQL de um campo, incluindo uma subseleção correlacionada. Segue-se um exemplo:

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. Segue-se um exemplo:

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 do tipo de campo do LookML

Quando faz referência a um campo LookML existente noutro campo, pode indicar ao Looker que trate o campo referenciado como um tipo de dados específico usando dois pontos (::) seguidos do tipo pretendido. Por exemplo, se fizer referência à dimensão orders.created_date noutro campo, pode usar a sintaxe ${orders.created_date::date} para garantir que o campo created_date é tratado como um campo de data no SQL gerado pelo Looker, em vez de ser convertido como uma string.

O tipo de dados que pode usar numa referência depende do tipo de dados do campo original ao qual está a fazer referência. Por exemplo, se estiver a fazer referência a um campo de string, o único tipo de dados que pode especificar é ::string. Segue-se a lista completa de referências de tipos de campos permitidas que pode usar para cada tipo de campo:

Numa referência a um campo de string, pode usar ::string.
Numa referência a um campo numérico, pode usar ::string e ::number.
Numa referência a um campo de data ou hora, pode usar ::string, ::date e ::datetime.
As referências que usam ::string e ::date devolvem dados no fuso horário de consulta, enquanto as referências que usam ::datetime devolvem dados no fuso horário da base de dados.
Numa referência a um campo yesno, pode usar ::string, ::number e ::boolean.
As referências de campos que usam o tipo ::boolean não estão disponíveis para dialetos de base de dados que não suportam o tipo de dados booleano.
Numa referência a um campo de localização, pode usar ::latitude e ::longitude.

Usar referências de tipos de campos LookML com campos de data

Por exemplo, suponhamos que tem uma dimensão enrollment_month e uma dimensão graduation_month, ambas 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 de type: time:


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

Com as dimensões enrollment_month e graduation_month, pode calcular quantos meses ou anos passaram entre a inscrição e a conclusão de um aluno criando um grupo de dimensões de type: duration. No entanto, uma vez que alguns campos de data são convertidos em strings no SQL gerado pelo Looker, a definição das dimensões enrollment_month e graduation_month como os valores de sql_start e sql_end pode resultar num erro.

Para evitar um erro resultante da conversão destes campos de tempo em strings, uma opção é criar um grupo de dimensões de type: duration, referindo-se aos intervalos de tempo de raw 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 Explorar, isto gera um grupo de dimensões denominado Duração da inscrição, com as dimensões individuais Meses de inscrição e Anos de inscrição.

Uma alternativa mais simples à utilização do período de raw num 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 Duration Enrolled, mas a utilização da referência ::date permite que as dimensões enrollment_month e graduation_month sejam usadas sem usar um período raw ou convertê-las em strings com SQL.

Para ver um exemplo adicional de como as referências do tipo de campo 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.

Esta sintaxe não está disponível com medidas de type: list, que não podem ser referenciadas a partir do Looker 6.8.

Constantes do LookML

O parâmetro constant permite-lhe especificar uma constante que pode usar num projeto do LookML. Com as constantes do LookML, pode definir um valor uma vez e referenciá-lo em qualquer parte do seu projeto onde as strings são aceites, reduzindo assim a repetição no seu código LookML.

As constantes têm de ser declaradas num ficheiro de manifesto do projeto, e o valor de uma constante tem de ser uma string. Por exemplo, pode definir uma constante city com o valor "Okayama" da seguinte forma:

constant: city {
  value: "Okayama"
}

Em seguida, pode fazer referência à constante city em todo o projeto através da sintaxe @{city}. Por exemplo, pode usar a constante city com o parâmetro label na secção users Explorar:


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

Em seguida, o Looker apresenta Utilizadores de Okayama no menu Explorar e no título da exploração, em vez de Utilizadores, que é o valor predefinido.

Para mais informações e exemplos de como pode usar constantes do LookML para escrever código reutilizável, consulte a página de documentação do parâmetro constant.

Incorporar SQL e referir-se a objetos do LookML Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.