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

Diese Seite wurde von der Cloud Translation API übersetzt.

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 Funktionsaufrufe Ihres Datenbankdialekts nutzen, um diese Werte zu bearbeiten.

Substitutionsoperator ($)

Der Substitutionsoperator $ macht LookML-Code wiederverwendbar und modularer, sodass Sie auf andere Ansichten und abgeleitete Tabellen, Spalten in einer SQL-Tabelle oder LookML-Dimensionen und ‐Messwerte verweisen können. Dies ist aus zwei Gründen sinnvoll. Erstens haben Sie vielleicht bereits eine wirklich schwierige Dimension oder einen kniffligen Messwert erarbeitet und müssen die gesamte Komplexität nicht noch einmal 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 Ansicht verbunden ist, an der Sie arbeiten. Beispiel:

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

${field_name} verweist auf eine Dimension oder ein Ergebnis in der Ansicht, in der Sie gerade 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. In diesem Verweis ist SQL_TABLE_NAME eine literale Zeichenfolge. Sie muss nicht 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 -Sätze 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> und werden nicht voneinander getrennt Punkt. Looker erweitert Kurznamen mithilfe des Scopes, in dem sie verwendet werden, zu vollständigen Namen.

Das folgende Beispiel zeigt viele Arten von Namen und Umfang. 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
    ]
  }
}

Beachten Sie in der dimension: customer_address-Deklaration, dass sich die zugrunde liegende Ansicht für den SQL-Block (customer) vom umschließenden Ansichtsbereich (orders) unterscheidet. Dies kann nützlich sein, wenn Sie Felder zwischen zwei verschiedenen Ansichten vergleichen müssen.

Wenn eine Ansicht – wir nennen sie "Ansicht A" – auf ein Feld verweist, das in einer anderen Ansicht definiert ist (wir nennen dies "Ansicht B"), müssen einige Dinge beachtet werden:

Die Datei von Ansicht B muss mithilfe des Parameters include im selben Modell wie Ansicht A enthalten sein.
Ansicht B muss in einem oder mehreren Explores mit Ansicht A verbunden sein. Auf der Seite Mit Joins in LookML arbeiten erfahren Sie mehr über Joins.

SQL-Dialekt

Looker unterstützt viele Datenbanktypen wie MySQL, Postgres, Redshift, BigQuery usw. Jede Datenbank unterstützt einen geringfügig anderen Funktionssatz mit unterschiedlichen Funktionsnamen. Diese werden als SQL-Dialekt bezeichnet.

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 verwenden (genannt SQL-Blöcke). 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 gängigste LookML-Parameter für SQL-Blöcke ist sql. Er wird in Dimensions- und Messwertfelddefinitionen verwendet, um den SQL-Ausdruck anzugeben, der die Dimension oder den Messwert 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. Beachten Sie, dass der in SQL-Blöcken verwendete Code mit dem von der Datenbank verwendeten SQL-Dialekt übereinstimmen muss.

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

Im Folgenden finden Sie Beispiele für SQL-Blöcke für Dimensionen und Messwerte. Der LookML-Substitutionsoperator ($) kann dazu führen, dass diese sql-Deklarationen anders als SQL erscheinen. Nach der Substitution ist der resultierende String jedoch reines SQL, das von Looker in die SELECT-Klausel der Abfrage eingeschleust wird.

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 zu sehen, 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 im SQL-Block eines Felds platzieren, einschließlich einer korrelierten Unterauswahl. Hier ein Beispiel:

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. Hier ein Beispiel:

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 Doppelpunkt (::) gefolgt vom gewünschten Typ. Wenn Sie beispielsweise in einem anderen Feld auf die Dimension orders.created_date verweisen, können Sie mit der Syntax ${orders.created_date::date} dafür sorgen, dass das Feld created_date in der von Looker generierten SQL-Anweisung als Datumsfeld behandelt wird, anstatt als String gecastet 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 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.
In Bezug auf ein Zahlenfeld können Sie ::string und ::number verwenden.
In einem Verweis auf ein Datums- oder Uhrzeitfeld 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.
In einem Verweis auf ein Ja/Nein-Feld können Sie ::string, ::number und ::boolean verwenden.
Feldbezüge vom Typ ::boolean sind für Datenbankdialekte, die den booleschen Datentyp nicht unterstützen, nicht verfügbar.
In einem Verweis auf ein Standortfeld können Sie ::latitude und ::longitude verwenden.

LookML-Feldtypreferenzen mit Datumsfeldern verwenden

Angenommen, Sie haben eine enrollment_month- und eine graduation_month-Dimension, die beide in Dimensionengruppen 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 ;;
}

Die Dimension graduation_month wird auf ähnliche Weise durch die folgende 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 Einschreibung und dem Abschluss eines Schülers/Studenten vergangen sind. Dazu erstellen Sie eine Dimensionsgruppe mit type: duration. Da einige Datumsfelder in der von Looker generierten SQL-Abfrage jedoch als Strings umgewandelt 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 Fehler zu vermeiden, die dadurch entstehen, dass diese Zeitfelder in Strings umgewandelt werden, können Sie eine Dimensionsgruppe mit type: duration erstellen, die auf die Zeiträume raw aus den 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} ;;
}

In der Explore-Benutzeroberfläche wird damit eine Dimensionsgruppe namens Dauer der Registrierung mit den einzelnen Dimensionen Registrierte Monate und Jahre der Registrierung generiert.

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


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

In der LookML in diesem Beispiel wird auch eine Dimensionsgruppe vom Typ Registrierte Dauer erstellt. Mit der ::date-Referenz können die Dimensionen enrollment_month und graduation_month jedoch ohne raw-Zeitraum verwendet oder mit SQL in Strings umgewandelt werden.

Ein weiteres Beispiel dafür, wie LookML-Feldtypen verwendet werden können, um benutzerdefinierte Dimensionsgruppen von type: duration zu erstellen, finden Sie auf der Dokumentationsseite zum Parameter dimension_group.

Diese Syntax ist nicht mit Messwerten von type: list verfügbar, auf die ab Looker 6.8 nicht mehr verwiesen werden kann.

LookML-Konstanten

Mit dem Parameter constant können Sie eine Konstante angeben, die Sie dann 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. So können Sie beispielsweise eine Konstante city mit dem Wert "Okayama" definieren:

constant: city {
  value: "Okayama"
}

Auf die Konstante city kann dann in Ihrem gesamten Projekt mit der Syntax @{city} verwiesen werden. Sie können beispielsweise die Konstante city mit dem Parameter label im Explore users verwenden:


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

Looker zeigt dann sowohl im Menü Explore als auch im Titel des Explores Okayama Users anstelle des standardmäßigen Users an.

Weitere Informationen und Beispiele dazu, wie Sie LookML-Konstanten zum Schreiben von wiederverwendbarem Code verwenden können, finden Sie auf der Dokumentationsseite zum Parameter constant.