SQL-Einbindung und Verweise auf LookML-Objekte

Um leistungsstarken LookML-Code zu schreiben, müssen Sie auch dann auf vorhandene Dimensionen, Messwerte, Ansichten oder abgeleitete Tabellen verweisen können, wenn sie nicht zum aktuellen Scope gehören. Außerdem müssen Sie auf Spalten in der zugrunde liegenden Tabelle verweisen und die Datenbankaufrufe Ihres Datenbankdialekts verwenden, um diese Werte zu bearbeiten.

Substitutionsoperator ($)

Mit dem Ersatzoperator $ wird der LookML-Code besser wiederverwendbar und modular. So können Sie auf andere Ansichten und abgeleitete Tabellen, Spalten in einer SQL-Tabelle oder auf LookML-Dimensionen und -Messwerte verweisen. Dies ist aus zwei Gründen sinnvoll. Möglicherweise haben Sie bereits eine knifflige Dimension oder Messung erarbeitet und müssen nicht noch einmal die komplexe Komplexität schreiben. Zweitens können Änderungen, die Sie an einer Dimension oder einem Messwert vornehmen, auf alles andere angewendet werden, das darauf zurückgreift.

Es gibt mehrere Möglichkeiten, den Substitutionsoperator zu verwenden:

${TABLE}.column_name verweist auf eine Spalte in der Tabelle, die mit der Ansicht verknüpft ist, an der Sie arbeiten. Beispiel:

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

${field_name} verweist auf eine Dimension oder einen Messwert in der Ansicht, an der Sie arbeiten. Beispiel:

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

${view_name.field_name} verweist auf eine Dimension oder einen Messwert aus einer anderen Ansicht. Beispiel:

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

${view_name.SQL_TABLE_NAME} verweist auf eine andere Ansicht oder abgeleitete Tabelle. Beachten Sie, dass SQL_TABLE_NAME in diesem Verweis ein Literalstring ist. Sie müssen nicht durch etwas ersetzt werden. Beispiel:

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} funktioniert nicht mit dem Parameter sql_trigger, der mit datagroups verwendet wird.

Scoping und Benennung

Sie können Explores, Ansichten, Feldern und Sätzen Namen geben. Diese Looker-Kennungen werden ohne Anführungszeichen geschrieben.

LookML-Felder und -Sets haben vollständige Namen und Kurznamen:

  • Vollständige Namen haben das Format <view>.<field-name | set-name>. Die linke Seite vor dem Punkt entspricht dem Scope, also der Ansicht, die das Feld bzw. den Satz enthält. Auf der rechten Seite wird der jeweilige Feld- oder Satzname angegeben.
  • Kurznamen haben einfach das Format <field-name | set-name> ohne Trennzeichen. Looker erweitert Kurznamen mithilfe des Scopes, in dem sie verwendet werden, zu vollständigen Namen.

Im Beispiel unten werden diverse Formen von Namen und Scopes dargestellt. Diese Gruppe von Feldern ist kein realistisches Beispiel, sondern soll lediglich veranschaulichen, wie viele verschiedene Möglichkeiten es für Scoping-Ausdrücke gibt.

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
    ]
  }
}

In der dimension: customer_address-Deklaration oben ist zu sehen, dass die zugrunde liegende Ansicht des SQL-Blocks (customer) sich von dem umgebenden Ansichtsbereich (orders) unterscheidet. Dies kann nützlich sein, wenn Sie Felder zwischen zwei verschiedenen Ansichten vergleichen müssen.

Wenn sich eine Ansicht (hier „View A“ genannt) auf ein Feld bezieht, das in einer anderen Ansicht definiert wurde (auch als „View B"“ bezeichnet), müssen Sie einige Dinge beachten:

  1. Die Datei B der Datenansicht B muss im selben Modell wie Datenansicht A enthalten sein und den Parameter include verwenden.
  2. Ansicht B muss in einem oder mehreren Explores mit Ansicht A verbunden sein. Weitere Informationen zu Joins finden Sie auf der Seite Mit Joins in LookML arbeiten.

SQL-Dialekt

Looker unterstützt viele Datenbanktypen wie MySQL, Postgres, Redshift, BigQuery usw. Jede Datenbank unterstützt einen etwas anderen Featuresatz mit unterschiedlichen Funktionsnamen, der als SQL-Dialekt bezeichnet wird.

LookML ist so konstruiert, dass alle SQL-Dialekte verwendet werden können, und es wird kein Dialekt gegenüber einem anderen bevorzugt. In bestimmten LookML-Parametern müssen jedoch SQL-Codeausdrücke (sogenannte SQL-Blöcke) angegeben werden. Mit diesen Parametern gibt Looker den SQL-Ausdruck direkt an Ihre Datenbank weiter. Das heißt, Sie müssen den SQL-Dialekt verwenden, der Ihrer Datenbank entspricht. Beispiel: Wenn Sie eine SQL-Funktion verwenden, muss dies eine Funktion sein, die Ihre Datenbank unterstützt.

SQL-Blöcke

Einige LookML-Parameter verlangen rohe SQL-Ausdrücke, damit Looker nachvollziehen kann, wie Daten aus Ihrer Datenbank abgerufen werden sollen.

Für LookML-Parameter, die mit sql_ beginnen, wird ein SQL-Ausdruck in irgendeiner Form erwartet. Beispiele: sql_always_where, sql_on und sql_table_name. Der gängigste LookML-Parameter für SQL-Blöcke ist sql. Er wird in den Definitionen von Dimensionen und Messwerten verwendet, um den SQL-Ausdruck anzugeben, der die Dimension oder das Maß definiert.

Der Code, den Sie in einem SQL-Block angeben, kann einfach sein, z. B. ein einzelner Feldname, oder komplex, z. B. eine korrelierte Unterauswahl. Der Inhalt kann recht komplex sein und fast jede denkbare Anforderung zum Ausdrücken benutzerdefinierter Abfragelogik in rohem SQL erfüllen. Der in SQL-Blöcken verwendete Code muss mit dem SQL-Dialekt der Datenbank übereinstimmen.

Beispiele für SQL-Blöcke für Dimensionen und Messwerte

Unten sind Beispiele für SQL-Blöcke für Dimensionen und Messwerte aufgeführt. Mit dem LookML-Ersetzungsoperator ($) können diese sql-Deklarationen im Gegensatz zu SQL auf betrügerische Weise angezeigt werden. Nach dem Ersetzen ist der resultierende String jedoch reiner SQL-Code, den Looker in die SELECT-Klausel der Abfrage einfügt.

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}) ;;
}

Wie in den letzten beiden Dimensionen oben gezeigt, können SQL-Blöcke Funktionen verwenden, die von der zugrunde liegenden Datenbank unterstützt werden (z. B. die MySQL-Funktionen CONCAT und DATEDIFF in diesem Beispiel).

Beispiel für einen SQL-Block mit einer korrelierten Unterauswahl

Sie können eine beliebige SQL-Anweisung in einen SQL-Block des Felds einfügen, einschließlich einer korrelierten Unterauswahl. Ein Beispiel ist unten aufgeführt:

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"
  }
}

Beispiel für einen SQL-Block für abgeleitete Tabellen

Abgeleitete Tabellen verwenden den SQL-Block, um die Abfrage zur Ableitung der Tabelle anzugeben. Ein Beispiel ist unten aufgeführt:

view: user_order_facts {
  derived_table: {
    sql:            # Get the number of orders for each user
      SELECT
        user_id
        , COUNT(&#42;) as lifetime_orders
      FROM orders
      GROUP BY 1 ;;
  }
  # later, dimension declarations reference the derived column(s)

  dimension: lifetime_orders {
    type: number
  }
}

LookML-Feldtypreferenzen

Wenn Sie auf ein vorhandenes LookML-Feld in einem anderen Feld verweisen, können Sie Looker anweisen, das referenzierte Feld als einen bestimmten Datentyp zu behandeln. Dazu verwenden Sie einen doppelten Doppelpunkt (::) gefolgt vom gewünschten Typ. Wenn Sie beispielsweise in einem anderen Feld auf die Dimension orders.created_date verweisen, können Sie mithilfe der Syntax ${orders.created_date::date} dafür sorgen, dass das Feld created_date als Datumsfeld in SQL behandelt und nicht als String umgewandelt wird.

Welchen Datentyp Sie in einem Feldbezug verwenden können, hängt vom Datentyp des ursprünglichen Feldes ab, auf das Sie sich beziehen. Wenn Sie beispielsweise auf ein Stringfeld verweisen, können Sie nur den Datentyp ::string angeben. Im Folgenden sehen Sie eine vollständige Liste der zulässigen Feldbezüge, die Sie für die einzelnen Felder verwenden können:

  • In einem Verweis auf ein Stringfeld können Sie ::string verwenden.
  • Als Verweis auf ein Zahlenfeld können Sie ::string und ::number verwenden.
  • Bei einem Verweis auf ein Datum oder eine Uhrzeit kannst du ::string, ::date und ::datetime verwenden.
    Referenzen, die ::string und ::date verwenden, geben Daten in der Zeitzone der Abfrage zurück, während Verweise, die ::datetime verwenden, Daten in der Zeitzone der Datenbank zurückgeben.
  • Für einen Verweis auf ein „yesno“-Feld können Sie ::string, ::number und ::boolean verwenden.
    Feldreferenzen mit dem Typ ::boolean sind nicht für Datenbankdialekte verfügbar, die den booleschen Datentyp nicht unterstützen.
  • Für einen Verweis auf ein Standortfeld können Sie ::latitude und ::longitude verwenden.

LookML-Feldtypreferenzen mit Datumsfeldern verwenden

Angenommen, Sie haben die Dimension enrollment_month und die Dimension graduation_month, die beide in Dimensionsgruppen von type: time erstellt wurden. In diesem Beispiel wird die Dimension enrollment_month von der folgenden Dimensionsgruppe von type: time generiert:


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

Ebenso wird die Dimension graduation_month von der folgenden Dimensionsgruppe von type: time erstellt:


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

Mit den Dimensionen enrollment_month und graduation_month können Sie berechnen, wie viele Monate oder Jahre zwischen der Anmeldung und dem Abschluss eines Schülers oder Studenten liegen, indem Sie eine Dimensionsgruppe „type: duration“ erstellen. Einige Datumsfelder werden jedoch als Strings in SQL umgewandelt, die Looker generiert. Wenn Sie die Dimensionen enrollment_month und graduation_month als Werte für sql_start und sql_end festlegen, kann das zu einem Fehler führen.

Um einen Fehler zu vermeiden, der entsteht, wenn diese Zeitfelder als Strings umgewandelt werden, können Sie eine Dimensionsgruppe von type: duration erstellen und auf die Zeiträume von raw aus den Dimensionsgruppen enrollment und graduation in den Parametern sql_start und sql_end verweisen:


dimension_group: enrolled {
  type: duration
  intervals: [month, year]
  sql_start: ${enrollment_raw} ;;
  sql_end: ${graduation_raw} ;;
}

Dadurch wird auf der Benutzeroberfläche „Erkunden“ eine Dimensionsgruppe mit dem Namen Dauer der Registrierung und den einzelnen Dimensionen Monate registriert und Jahresregistrierung erstellt.

Eine einfachere Alternative zur Verwendung des Zeitraums raw in einer Dimensionsgruppe von type: duration ist die Angabe des Referenztyps ::date oder ::datetime für die Felder, auf die in den Parametern sql_start und sql_end verwiesen wird.


dimension_group: enrolled {
  type: duration
  intervals: [month, year]
  sql_start: ${enrollment_month::date} ;;
  sql_end: ${graduation_month::date} ;;
}

In diesem Beispiel wird durch die LookML auch eine Dimensionsgruppe für die Dauer der Registrierung erstellt. Wenn Sie aber die Referenz ::date verwenden, können die Dimensionen enrollment_month und graduation_month verwendet werden, ohne dass ein raw-Zeitraum verwendet oder als Strings mit SQL umgewandelt werden muss.

Ein weiteres Beispiel dafür, wie Sie mithilfe von Verweisen auf den LookML-Feldtyp benutzerdefinierte Dimensionsgruppen für type: duration erstellen können, finden Sie auf der Dokumentationsseite zum Parameter dimension_group.

Diese Syntax ist nicht für Messwerte von type: list verfügbar, auf die mit Looker 6.8 nicht verwiesen werden kann.

LookML-Konstanten

Mit dem Parameter constant können Sie eine Konstante angeben, die Sie in einem LookML-Projekt verwenden können. Mit LookML-Konstanten können Sie einen Wert einmal definieren und dann in jedem beliebigen Teil Ihres Projekts referenzieren, in dem Zeichenfolgen akzeptiert werden. Dadurch wird die Anzahl der Wiederholungen in Ihrem LookML-Code verringert.

Konstanten müssen in einer Projekt-Manifestdatei deklariert werden und als Wert für Konstanten müssen Zeichenfolgen verwendet werden. Sie können beispielsweise eine Konstante city mit dem Wert "Okayama" definieren:

constant: city {
  value: "Okayama"
}

Auf die Konstante city kann dann während des gesamten Projekts mit der Syntax @{city} verwiesen werden. Beispielsweise können Sie die Konstante city mit dem Parameter label im users-Erkunden verwenden:


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

Looker zeigt dann OKama-Nutzer sowohl im Menü Erkunden als auch im Titel der Ansicht statt in den standardmäßigen Nutzern an.

Weitere Informationen und Beispiele für die Verwendung von LookML-Konstanten zum Schreiben von wiederverwendbarem Code finden Sie auf der Dokumentationsseite zum Parameter constant.