Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

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 diese Werte mithilfe der Funktionsaufrufe des Datenbankdialekts bearbeiten.

Substitutionsoperator ($)

Der Substitutionsoperator $ macht den LookML-Code wiederverwendbarer und modularer. So können Sie auf andere Ansichten und abgeleitete Tabellen, Spalten in einer SQL-Tabelle oder LookML-Dimensionen und -Messwerte verweisen. Dies ist aus zwei Gründen sinnvoll. Erstens haben Sie vielleicht schon eine knifflige Dimension oder Messung entwickelt und müssen nicht noch einmal den komplizierten Namen aufschreiben. 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 zu bearbeitenden Ansicht verbunden ist. 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. SQL_TABLE_NAME ist in dieser Referenz ein literaler String. Sie müssen ihn nicht durch etwas ersetzen. 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 für Datengruppen 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 kurze Namen:

Vollständige Namen haben die Form <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 obigen dimension: customer_address-Deklaration wurde für den SQL-Block (customer) eine andere Ansicht als die einschließende Ansicht (orders) festgelegt. Das kann hilfreich sein, wenn Sie Felder zwischen zwei verschiedenen Ansichten vergleichen möchten.

Wenn sich eine Ansicht (die sogenannte „Ansicht A“) auf ein Feld bezieht, das in einer anderen Ansicht definiert wird (wird als „Ansicht B“ bezeichnet), müssen einige Dinge beachtet werden:

Die Datei B der Datenansicht muss im selben Modell wie Datenansicht A enthalten sein. Verwenden Sie dazu den Parameter include.
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, z. B. MySQL, Postgres, Redshift, BigQuery usw. Jede Datenbank unterstützt einen etwas anderen Feature-Set 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 Sie jedoch SQL-Codeausdrücke, auch SQL-Blöcke genannt, verwenden. 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.

LookML-Parameter, die mit sql_ beginnen, erwarten einen SQL-Ausdruck in irgendeiner Form. Beispiele: sql_always_where, sql_on und sql_table_name. Der häufigste LookML-Parameter für SQL-Blöcke ist sql. Er wird in Definitionen für Dimensionen und Messwerte 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 von der Datenbank verwendeten SQL-Dialekt ü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-Substitutionsoperator ($) können diese sql-Deklarationen betrügerisch anders aussehen als SQL. Der Ersatzstring ist nach dem Ersetzen 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 jede SQL-Anweisung im SQL-Block eines Felds platzieren, auch in einer korrelierten Subauswahl. 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(*) 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 auf die Dimension orders.created_date in einem anderen Feld verweisen, können Sie die Syntax ${orders.created_date::date} verwenden, damit das Feld created_date als Datumsfeld in SQL behandelt wird, anstatt als String umgewandelt zu werden.

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 ::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.
In einem Feld mit einer Zahl können Sie ::string und ::number verwenden.
In einem Feld vom Typ „Datum“ oder „Uhrzeit“ können Sie ::string, ::date und ::datetime verwenden.
Referenzen mit ::string und ::date geben Daten in der Zeitzone der Abfrage zurück, während Verweise mit ::datetime Daten in der Zeitzone der Datenbank zurückgeben.
Als Verweis auf ein „yes“-Feld können Sie ::string, ::number und ::boolean verwenden.
Feldreferenzen, die den Typ ::boolean verwenden, sind nicht für Datenbankdialekte verfügbar, die den booleschen Datentyp nicht unterstützen.
In einem Verweis auf einen 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. Beide wurden in Dimensionsgruppen von type: time erstellt. In diesem Beispiel wird die Dimension enrollment_month durch die folgende 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 durch die folgende Dimensionsgruppe von type: time erstellt:


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

Mithilfe der Dimensionen enrollment_month und graduation_month können Sie berechnen, wie viele Monate oder Jahre zwischen der Anmeldung und dem Abschluss eines Schülers vergangen sind, indem Sie eine Dimensionsgruppe von type: duration erstellen. Da jedoch einige Datumsfelder als Strings in SQL umgewandelt werden, die von Looker generiert werden, kann das Festlegen der Dimensionen enrollment_month und graduation_month als Werte für sql_start und sql_end zu einem Fehler führen.

Um einen Fehler zu vermeiden, der dadurch verursacht wird, dass diese Zeitfelder als Strings gestreamt werden, können Sie eine Dimensionsgruppe von type: duration erstellen, die auf die Zeiträume raw der Dimensionsgruppen enrollment und graduation in den Parametern sql_start und sql_end verweist:


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 registriert und den einzelnen Dimensionen Monate registriert und Jahre registriert erstellt.

Eine einfachere Alternative zur Verwendung des Zeitraums raw in einer Dimensionsgruppe von type: duration ist, den Referenztyp ::date oder ::datetime für die Felder anzugeben, 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 Dauer registriert erstellt. Wenn Sie jedoch 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 Verweise auf LookML-Feldtypen zum Erstellen benutzerdefinierter Dimensionsgruppen von type: duration verwendet werden können, finden Sie auf der Seite mit der Parameterdokumentation zu dimension_group.

Diese Syntax ist für Messwerte von type: list nicht verfügbar, auf die in 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 mit der Syntax @{city} im gesamten Projekt verwiesen werden. So können Sie beispielsweise die Konstante city mit dem Parameter label in der Funktion users verwenden:


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

In Looker wird dann im Menü Erkunden und im Titel des explorativen Analysetools Okayama-Nutzer angezeigt und nicht die Standardeinstellung Nutzer.

Weitere Informationen und Beispiele dazu, wie Sie wiederverwendbaren Code mit LookML-Konstanten schreiben können, finden Sie auf der Dokumentationsseite zu constant-Parametern.