Per scrivere un LookML efficace, devi essere in grado di fare riferimento a dimensioni, misure, viste o tabelle derivate esistenti anche se non rientrano nell'ambito attuale. Devi anche fare riferimento alle colonne nella tabella sottostante e utilizzare le chiamate alle funzioni del dialetto del database per manipolare tali valori.
Operatore di sostituzione ($)
L'operatore di sostituzione $, rende il codice LookML più riutilizzabile e modulare, consentendoti di fare riferimento ad altre viste e tabelle derivate, a colonne in una tabella SQL o a dimensioni e misure LookML. Questo è valido per due motivi. Innanzitutto, potresti aver già creato una dimensione o una misurazione molto complessa e non hai bisogno di riscrivere tutta la complessità. In secondo luogo, se modifichi qualcosa in merito a una dimensione o una misurazione, tale modifica può propagarsi a qualsiasi altro elemento su cui si basa.
Puoi utilizzare l'operatore di sostituzione in diversi modi:
${TABLE}.column_name fa riferimento a una colonna della tabella collegata alla vista su cui stai lavorando. Ad esempio:
dimension: customer_id {
type: number
sql: ${TABLE}.customer_id ;;
}
${field_name} fa riferimento a una dimensione o una misurazione all'interno della visualizzazione su cui stai lavorando. Ad esempio:
measure: total_population {
type: sum
sql: ${population} ;;
}
${view_name.field_name} fa riferimento a una dimensione o a una misurazione da un'altra vista. Ad esempio:
dimension: lifetime_orders {
type: number
sql: ${user_order_facts.lifetime_orders} ;;
}
${view_name.SQL_TABLE_NAME} fa riferimento a un'altra visualizzazione o tabella derivata. Tieni presente che il riferimento SQL_TABLE_NAME in questa stringa è letterale e non è necessario sostituirlo con nulla. Ad esempio:
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}non funziona con il parametrosql_triggerutilizzato con datagroups.
Scoping e denominazione
Puoi assegnare un nome a Esplorazioni, visualizzazioni, campi e insiemi. Questi identificatori di Looker sono scritti senza virgolette.
I campi e i set di LookML hanno nomi completi e nomi brevi:
- I nomi completi sono nel formato
<view>.<field-name | set-name>. Il lato sinistro indica l'ambito, che corrisponde alla vista contenente il campo o l'insieme. Sul lato destro viene specificato il campo o il nome dell'insieme specifico. - I nomi brevi prendono semplicemente il formato
<field-name | set-name>, senza punto di separazione. Looker espande i nomi brevi in nomi completi utilizzando l'ambito in cui vengono utilizzati.
Di seguito è riportato un esempio di molti nomi e ambiti. Si tratta di un gruppo non realistico di campi, ma viene mostrato per dimostrare una varietà di possibili espressioni di definizione dell'ambito.
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
]
}
}
Nella dichiarazione dimension: customer_address riportata sopra, tieni presente che la vista sottostante per il blocco SQL (customer) è diversa dall'ambito della vista che lo contiene (orders). Ciò può essere utile quando devi confrontare i campi tra due viste diverse.
Quando una vista (noi la chiamiamo "vista A") si riferisce a un campo definito in un'altra vista (noi la chiamiamo "vista B"), ci sono alcuni aspetti da tenere presente:
- Il file della vista B deve essere incluso nello stesso modello della vista A, utilizzando il parametro
include. - La vista B deve essere inclusa nella vista A in una o più esplorazioni. Per informazioni sui join, consulta la nostra pagina Utilizzo dei join in LookML.
Dialetto SQL
Looker supporta diversi tipi di database, tra cui MySQL, Postgres, Redshift, BigQuery e così via. Ogni database supporta un set di funzionalità leggermente diverso con nomi di funzioni diversi, denominato linguaggio SQL.
LookML è progettato per funzionare con tutti i dialetti SQL e LookML non preferisce un dialetto rispetto all'altro. Tuttavia, dovrai includere espressioni di codice SQL (note come blocchi SQL) in determinati parametri LookML. Con questi parametri, Looker trasmette l'espressione SQL direttamente al tuo database, quindi devi utilizzare il dialetto SQL corrispondente al tuo database. Ad esempio, se utilizzi una funzione SQL, deve essere una funzione supportata dal tuo database.
Blocchi SQL
Alcuni parametri LookML richiedono di fornire espressioni SQL non elaborate per consentire a Looker di comprendere come recuperare i dati dal tuo database.
I parametri LookML che iniziano con sql_ prevedono un'espressione SQL di qualche tipo. Alcuni esempi sono: sql_always_where, sql_on e sql_table_name. Il parametro LookML più comune per i blocchi SQL è sql, utilizzato nelle definizioni dei campi di dimensione e misurazione per specificare l'espressione SQL che definisce la dimensione o la misura.
Il codice specificato in un blocco SQL può essere semplice come un singolo nome di campo o complesso come una sottoselezione correlata. I contenuti possono essere piuttosto complessi e possono soddisfare quasi tutte le esigenze che potresti dover esprimere nella logica delle query personalizzate in SQL non elaborato. Ricorda che il codice che utilizzi nei blocchi SQL deve corrispondere al linguaggio SQL utilizzato dal database.
Esempi di blocchi SQL per dimensioni e misure
Di seguito sono riportati alcuni esempi di blocchi SQL per dimensioni e misure. L'operatore di sostituzione LookML ($) può far apparire queste dichiarazioni sql in modo ingannevole a differenza di SQL. Tuttavia, dopo la sostituzione, la stringa risultante è SQL puro, che Looker inserisce nella clausola SELECT della query.
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}) ;;
}
Come mostrato nelle ultime due dimensioni precedenti, i blocchi SQL possono utilizzare le funzioni supportate dal database sottostante (come le funzioni MySQL CONCAT e DATEDIFF in questo esempio).
Esempio di blocco SQL con una selezione secondaria correlata
Puoi inserire qualsiasi istruzione SQL in un blocco SQL di un campo, inclusa una relativa selezione secondaria. Di seguito è riportato un esempio:
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"
}
}
Esempio di blocco SQL per le tabelle derivate
Le tabelle derivate utilizzano il blocco SQL per specificare la query che deriva la tabella. Di seguito è riportato un esempio:
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
}
}
Riferimenti per i tipi di campo LookML
Quando fai riferimento a un campo LookML esistente in un altro campo, puoi indicare a Looker di trattare il campo cui si fa riferimento come un tipo di dati specifico utilizzando i due punti (::) seguiti dal tipo desiderato. Ad esempio, se fai riferimento alla dimensione orders.created_date all'interno di un altro campo, puoi utilizzare la sintassi ${orders.created_date::date} per assicurarti che il campo created_date venga considerato come un campo di data nell'SQL generato da Looker, anziché essere trasmesso come stringa.
Il tipo di dati che puoi utilizzare in un riferimento dipende dal tipo di dati del campo originale a cui fai riferimento. Ad esempio, se fai riferimento a un campo stringa, l'unico tipo di dati che puoi specificare è ::string. Ecco l'elenco completo dei riferimenti consentiti per i tipi di campi che puoi utilizzare per ciascun tipo di campo:
- In un campo stringa, puoi utilizzare
::string. - In un campo numerico, puoi utilizzare
::stringe::number. - In un riferimento a un campo data o ora, puoi utilizzare
::string,::datee::datetime.
I riferimenti che utilizzano::stringe::daterestituiscono i dati nel fuso orario della query, mentre i riferimenti che utilizzano::datetimerestituiscono i dati nel fuso orario del database. - In riferimento a un campo sì, puoi utilizzare
::string,::numbere::boolean.
I riferimenti ai campi che utilizzano il tipo::booleannon sono disponibili per i dialetti del database che non supportano il tipo di dati booleani. - In un campo località, puoi utilizzare
::latitudee::longitude.
Utilizzo dei riferimenti ai tipi di campo LookML con i campi data
Ad esempio, supponi di avere una dimensione enrollment_month e una dimensione graduation_month, entrambe create all'interno di gruppi di dimensioni di type: time. In questo esempio, la dimensione enrollment_month viene prodotta dal seguente gruppo di dimensioni type: time:
dimension_group: enrollment {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.enrollment_date ;;
}
Allo stesso modo, la dimensione graduation_month viene creata dal seguente gruppo di dimensioni type: time:
dimension_group: graduation {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.graduation_date ;;
}
Utilizzando le dimensioni enrollment_month e graduation_month, puoi calcolare quanti mesi o anni sono trascorsi tra la registrazione e la laurea di uno studente creando un gruppo di dimensioni type: duration. Tuttavia, poiché alcuni campi di date vengono trasmessi come stringhe nell'SQL generato da Looker, l'impostazione delle dimensioni enrollment_month e graduation_month come valori per sql_start e sql_end può causare un errore.
Per evitare un errore derivante da questi campi temporali trasmessi come stringhe, una possibilità è creare un gruppo di dimensioni type: duration, facendo riferimento ai periodi di tempo raw dai gruppi di dimensioni enrollment e graduation nei parametri sql_start e sql_end:
dimension_group: enrolled {
type: duration
intervals: [month, year]
sql_start: ${enrollment_raw} ;;
sql_end: ${graduation_raw} ;;
}
Nell'interfaccia utente di Esplora, viene generato un gruppo di dimensioni chiamato Durata registrazione, con singole dimensioni Mesi registrati e Anni di registrazione.
Un'alternativa più semplice all'utilizzo del periodo di tempo raw in un gruppo di dimensioni type: duration è specificare il tipo di riferimento ::date o ::datetime per i campi a cui viene fatto riferimento nei parametri sql_start e sql_end.
dimension_group: enrolled {
type: duration
intervals: [month, year]
sql_start: ${enrollment_month::date} ;;
sql_end: ${graduation_month::date} ;;
}
In questo esempio, il codice LookML crea anche un gruppo di dimensioni Durata registrazione, ma l'utilizzo del riferimento ::date consente di utilizzare le dimensioni enrollment_month e graduation_month senza utilizzare un periodo di tempo raw o trasmetterle come stringhe con SQL.
Per un ulteriore esempio di come i riferimenti ai tipi di campi LookML possono essere utilizzati per creare gruppi di dimensioni personalizzate type: duration, consulta la pagina della documentazione relativa al parametro dimension_group.
Questa sintassi non è disponibile con misure di
type: list, a cui non si può fare riferimento a partire da Looker 6.8.
Costanti LookML
Il parametro constant consente di specificare una costante utilizzabile in un progetto LookML. Con le costanti LookML, puoi definire un valore una sola volta e fare riferimento a quest'ultimo in qualsiasi parte del progetto in cui le stringhe sono accettate, riducendo così la ripetizione nel codice LookML.
Le costanti devono essere dichiarate all'interno di un file manifest del progetto e il valore di una costante deve essere una stringa. Ad esempio, puoi definire una costante city con il valore "Okayama" nel seguente modo:
constant: city {
value: "Okayama"
}
Puoi fare riferimento alla costante city in tutto il progetto utilizzando la sintassi @{city}. Ad esempio, puoi utilizzare la costante city con il parametro label nell'esplorazione users:
explore: users {
label: "@{city} Users"
}
Looker visualizza quindi gli utenti di Okayama sia nel menu Esplora sia nel titolo dell'esplorazione, anziché negli utenti predefiniti.
Per ulteriori informazioni ed esempi su come utilizzare le costanti LookML per scrivere codice riutilizzabile, consulta la pagina della documentazione relativa al parametro constant.