Per scrivere un codice LookML efficace, devi essere in grado di fare riferimento a dimensioni, misure, visualizzazioni o tabelle derivate esistenti anche se non sono nell'ambito corrente. Devi anche fare riferimento alle colonne della tabella sottostante e utilizzare le chiamate alle funzioni del dialetto del database per manipolare questi 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, colonne in una tabella SQL o dimensioni e misure di LookML. Questo è positivo per due motivi. Innanzitutto, potresti aver già elaborato una dimensione o una misura molto complessa e non dovrai riscrivere tutta la complessità. In secondo luogo, se modifichi un aspetto di una dimensione o di una misura, la modifica può essere applicata a tutto ciò che si basa su questa dimensione o misura.
Esistono diversi modi per utilizzare l'operatore di sostituzione:
${TABLE}.column_name fa riferimento a una colonna della tabella collegata alla visualizzazione su cui stai lavorando. Ad esempio:
dimension: customer_id {
type: number
sql: ${TABLE}.customer_id ;;
}
${field_name} fa riferimento a una dimensione o una misura 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 una misura di un'altra visualizzazione. 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 a una tabella derivata. Tieni presente che SQL_TABLE_NAME in questo riferimento è una stringa letterale; non devi sostituirla 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.
Scopo e denominazione
Puoi assegnare un nome a esplorazioni, visualizzazioni, campi e set. Questi identificatori di Looker vengono scritti senza virgolette.
I campi e gli insiemi di LookML hanno nomi completi e nomi brevi:
- I nomi completi sono del tipo
<view>.<field-name | set-name>. Il lato sinistro indica l'ambito, ovvero la visualizzazione contenente il campo o l'insieme. Il lato destro specifica il nome del campo o dell'insieme specifico. - I nomi brevi hanno semplicemente la forma
<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 che mostra molte forme di nomi e ambito. Si tratta di un gruppo di campi non realistico, ma viene mostrato per dimostrare una serie di possibili espressioni di 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, tieni presente che la visualizzazione sottostante per il blocco SQL (customer) è diversa dall'ambito della visualizzazione contenente (orders). Questo può essere utile quando devi confrontare i campi di due visualizzazioni diverse.
Quando una visualizzazione (chiamiamola "visualizzazione A") fa riferimento a un campo definito in un'altra visualizzazione (chiamiamola "visualizzazione B"), devi tenere presente alcune cose:
- Il file della visualizzazione B deve essere incluso nello stesso modello della visualizzazione A utilizzando il parametro
include. - La vista B deve essere unita alla vista A in una o più esplorazioni. Per saperne di più sulle unioni, consulta la pagina Utilizzare le unioni in LookML.
Dialetto SQL
Looker supporta molti tipi di database, come MySQL, Postgres, Redshift, BigQuery e così via. Ogni database supporta un insieme di funzionalità leggermente diverso con nomi di funzioni diversi, denominato dialetto SQL.
LookML è progettato per funzionare con tutti i dialetti SQL e 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 passa l'espressione SQL direttamente al 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 in modo che Looker possa capire come recuperare i dati dal database.
I parametri LookML che iniziano con sql_ richiedono un'espressione SQL di qualche forma. 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 delle dimensioni e delle misure 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 sottosezione correlata. I contenuti possono essere piuttosto complessi e soddisfare quasi tutte le esigenze di espressione della logica di query personalizzata in SQL non elaborato. Tieni presente che il codice utilizzato nei blocchi SQL deve corrispondere al dialetto SQL utilizzato dal database.
Blocchi SQL di esempio per dimensioni e misure
Di seguito sono riportati esempi di blocchi SQL per dimensioni e misure. L'operatore di sostituzione LookML ($) può far sembrare queste dichiarazioni sql ingannevolmente diverse da 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, i blocchi SQL possono utilizzare le funzioni supportate dal database sottostante (ad esempio le funzioni MySQL CONCAT e DATEDIFF in questo esempio).
Esempio di blocco SQL con una sottosezione correlata
Puoi inserire qualsiasi istruzione SQL nel blocco SQL di un campo, inclusa una sottosezione correlata. 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"
}
}
Blocco SQL di esempio per le tabelle derivate
Le tabelle derivate utilizzano il blocco SQL per specificare la query da cui viene derivata 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 ai tipi di campo LookML
Quando fai riferimento a un campo LookML esistente all'interno di un altro campo, puoi indicare a Looker di trattare il campo a cui fai riferimento come un tipo di dati specifico utilizzando due 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 trattato come un campo di date nel codice SQL generato da Looker, anziché essere eseguito il casting 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 di stringhe, l'unico tipo di dati che puoi specificare è ::string. Di seguito è riportato l'elenco completo dei riferimenti ai tipi di campo consentiti che puoi utilizzare per ogni tipo di campo:
- In un riferimento a un campo di stringhe, puoi utilizzare
::string. - In un riferimento a un campo numerico, puoi utilizzare
::stringe::number. - In un riferimento a un campo di 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 un riferimento a un campo yesno, puoi utilizzare
::string,::numbere::boolean. I riferimenti ai campi che utilizzano il tipo::booleannon sono disponibili per i dialetti di database che non supportano il tipo di dati booleano. - In un riferimento a un campo posizione, puoi utilizzare
::latitudee::longitude.
Utilizzare i riferimenti ai tipi di campo LookML con i campi della data
Ad esempio, supponiamo 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 di type: time:
dimension_group: enrollment {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.enrollment_date ;;
}
Analogamente, la dimensione graduation_month viene creata dal seguente gruppo di dimensioni di 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 il numero di mesi o anni trascorsi tra l'iscrizione e la laurea di uno studente creando un gruppo di dimensioni di type: duration. Tuttavia, poiché alcuni campi della data vengono trasmessi come stringhe nel codice SQL generato da Looker, l'impostazione delle dimensioni enrollment_month e graduation_month come valori per sql_start e sql_end può comportare un errore.
Per evitare un errore derivante dal fatto che questi campi di tempo vengono trasmessi come stringhe, un'opzione è creare un gruppo di dimensioni di type: duration facendo riferimento ai periodi di tempo raw dei 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 denominato Durata dell'iscrizione, con le singole dimensioni Mese di iscrizione e Anno di iscrizione.
Un'alternativa più semplice all'utilizzo dell'intervallo di tempo raw in un gruppo di dimensioni di 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} ;;
}
Il codice LookML in questo esempio crea anche un gruppo di dimensioni Durata iscritti, ma l'utilizzo del riferimento ::date consente di utilizzare le dimensioni enrollment_month e graduation_month senza utilizzare un periodo di tempo raw o eseguirne il casting come stringhe con SQL.
Per un altro esempio di come i riferimenti ai tipi di campo LookML possono essere utilizzati per creare gruppi di dimensioni personalizzate di type: duration, consulta la pagina della documentazione del parametro dimension_group.
Questa sintassi non è disponibile con le misure di
type: list, a cui non è possibile fare riferimento a partire da Looker 6.8.
Costanti di LookML
Il parametro constant ti consente di specificare una costante da utilizzare in un progetto LookML. Con le costanti LookML, puoi definire un valore una volta e farvi riferimento in qualsiasi parte del progetto in cui sono accettate le stringhe, riducendo così le ripetizioni 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" come segue:
constant: city {
value: "Okayama"
}
È quindi possibile 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 mostra quindi Utenti di Okayama sia nel menu Esplora sia nel titolo dell'esplorazione, anziché Utenti predefinito.
Per ulteriori informazioni ed esempi su come utilizzare le costanti di LookML per scrivere codice riutilizzabile, consulta la pagina della documentazione del parametro constant.