Dimensions-, Filter- und Parametertypen

Diese Seite bezieht sich auf den Parameter type, der Teil einer Dimension oder eines Filters ist.

type kann auch als Teil einer Messung verwendet werden, wie auf der Dokumentationsseite zu Messtypen beschrieben.

type kann auch als Teil einer Dimensionsgruppe verwendet werden, wie auf der Dokumentationsseite zum Parameter dimension_group beschrieben.

Nutzung

view: view_name {
Dimension: Feldname {
Typ: field_type
}
}
Hierarchie
view
Feldtyp
type
Mögliche Feldtypen
Dimension, Filter, Parameter

Standardwert
string

Akzeptiert
Dimension, Filter oder Parametertyp

Auf dieser Seite finden Sie weitere Informationen zu den verschiedenen Typen, die einem dimension, filter oder parameter zugewiesen werden können. Eine Dimension, ein Filter oder ein Parameter kann nur einen Typ haben. Wenn kein Typ angegeben ist, wird standardmäßig string verwendet.

Einige Typen haben unterstützende Parameter, die im entsprechenden Abschnitt beschrieben werden.

Typdefinitionen

D = Dimension
DG = Dimensionsgruppe
F = Filtern
P = Parameter
Typ Beschreibung Gültige Feldtypen
bin ADDED 21.14 Für Felder, die numerische Werte in mehreren Bereichen gruppieren D
date Für Felder mit Datumsangaben D F P
date_time Für Felder mit Datumsangaben und Uhrzeiten D F P
distance Für Felder, die die Entfernung des direktesten Pfads („als Luftlinie“) zwischen zwei type: location-Dimensionen berechnen D
duration Wird mit einem dimension_group verwendet, um mehrere dauerbasierte Dimensionen aus einer einzelnen Tabellenspalte zu erstellen. Informationen zu Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. DG
location Für Felder, die auf Breiten- und Längengrad basieren und in Visualisierungen verwendet werden D
number Für Felder mit Zahlen D F P
string Für Felder, die Buchstaben oder Sonderzeichen enthalten D F P
tier Für Felder, die numerische Werte in mehreren Bereichen gruppieren D
time Wird mit einem dimension_group verwendet, um mehrere zeitbasierte Dimensionen aus einer einzelnen Tabellenspalte zu erstellen. Informationen zu Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. DG
unquoted Für parameter-Felder, deren Werte direkt in SQL eingefügt und daher nicht in Anführungszeichen gesetzt werden sollen (wie bei type: string)
yesno Für Felder, die angeben, ob etwas wahr oder falsch ist D F P
zipcode Für Felder mit einer Postleitzahl, die in Visualisierungen verwendet werden D
Individuelle Zeit- und Datumstypen Eine selten verwendete Alternative zu type: time zum Erstellen einzelner, zeitbasierter Dimensionen D F
Individuelle Dauertypen Eine selten verwendete Alternative zu type: duration zum Erstellen einzelner zeitbasierter Dimensionen zur Berechnung von Zeitunterschieden D
int REMOVED 5.4 Ersetzt durch type: number D

bin

type: bin ist ein Alias für type: tier. Beide Typen sind austauschbar.

type: bin wird in Verbindung mit dem Parameter bins verwendet, um eine numerische Dimension in eine Reihe von Zahlenbereichen zu unterteilen. Sie können beispielsweise eine Dimension „Alter“ in verschiedene Altersgruppen einordnen. Sie können die Darstellung der Klassen in der Looker-Benutzeroberfläche mit dem Parameter style ändern.

Das Nutzungsmuster lautet:

view: view_name {
Dimension: Feldname {
Typ: bin
bin: [numerischer_Wert, numerischer_Wert, ... ]
Stil: Intervall
sql: ${my_field_name}
}

Der Parameter sql für type: bin-Dimensionen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer Zahl oder Ganzzahl führt.

Das obige Beispiel für das Alter könnte so aussehen:

dimension: age_bin {
  type: bin
  bins: [0, 10, 20, 30, 40, 50, 60, 70, 80, 90]
  style: interval
  sql: ${age} ;;
}

Wie dies auf der Looker-Benutzeroberfläche aussehen würde, wird im Abschnitt style für den Parameter type: tier auf dieser Seite beschrieben.

Der Typ bin ist ein Alias für type: tier. Die beiden Typen können austauschbar verwendet werden und das Verhalten für beide ist gleich:

  • Der Unterparameter style wird verwendet, um die Darstellung von Klassen in der Looker-Benutzeroberfläche anzupassen.
  • Dimensions of type: bin kann nicht in benutzerdefinierten Filtern verwendet werden.
  • Die Verwendung von type: bin in Verbindung mit der Dimensionsfüllung kann zu unerwarteten Stufen-Buckets führen.

distance

type: distance wird verwendet, um die Entfernung des direktesten Pfads (als Luftlinie) zwischen zwei type: location-Dimensionen zu berechnen.

Der Parameter sql ist für type: distance Dimensionen ausgeschlossen. Stattdessen geben Sie in den Parametern start_location_field und end_location_field einen Verweis auf eine type: location-Dimension an.

Die Nutzung sieht so aus:

view: view_name {
dimension: field_name {
Typ: Entfernung
start_location_field: field_name_1
end_location_field: field_name_2
units: Kilometer

Die Einheit für die Entfernung wird durch den Parameter units bestimmt, der die folgenden Werte annehmen kann:

  • feet
  • kilometers
  • meters
  • miles
  • nautical_miles
  • yards

So können Sie beispielsweise die Strecke berechnen, die ein Kunde zur Abholung eines Mietobjekts zurückgelegt hat:

dimension: distance_to_pickup {
  type: distance
  start_location_field: customer.home_location
  end_location_field: rental.pickup_location
  units: miles
}

Die berechnete Entfernung ist der direkteste Weg zwischen den beiden Punkten, nicht unbedingt die zurückgelegte Entfernung der Straße.

Verwenden Sie die Syntax ${view_name.field_name} nicht in den Parametern start_location_field und end_location_field. Verwenden Sie stattdessen den Namen der Ansicht und des Feldnamens allein, z. B. view_name.field_name.

duration

type: duration wird in Verbindung mit einem dimension_group verwendet, um eine Reihe von berechneten Zeitunterschieden zwischen Dimensionen und/oder SQL-Ausdrücken zu erstellen.

type: duration funktioniert nur mit einem dimension_group und nicht mit einem normalen dimension. Sie können jedoch wie in diesem Abschnitt unten beschrieben individuelle Dimensionen für die Dauer festlegen.

Informationen zu Dimensionsgruppen mit type: duration finden Sie in der Dokumentation des Parameters dimension_group.

location

type: location wird in Verbindung mit den Parametern sql_latitude und sql_longitude verwendet, um Koordinaten zu erstellen, die Sie auf einer Karte oder einer statischen Karte (Punkt) darstellen möchten. Verwenden Sie dazu ein Bundesland- oder Länderfeld für die statische Karte (Regionen) oder die für eine type: distance-Berechnung.

Das Nutzungsmuster lautet:

view: view_name {
Dimension: Feldname {
Typ: location
sql_latitude:${field_name_1} ;;
sql_length:${field_name_2} ;;
}
}

Der Parameter sql ist für type: location Dimensionen ausgeschlossen. Stattdessen geben Sie alle gültigen SQL-Ausdrücke an, die zu einem dezimalen Längen- oder Breitengrad für die Parameter sql_latitude und sql_longitude führen. Dies sind in der Regel Verweise auf LookML-Felder, die Informationen zu Breiten- und Längengraden enthalten. Es kann sich aber auch um statische Werte handeln, wenn Sie einen Hauptsitz oder eine ähnliche Adresse haben möchten.

Die Dimension store_location könnte beispielsweise so aussehen:

dimension: store_location {
  type: location
  sql_latitude: ${store_latitude} ;;
  sql_longitude: ${store_longitude} ;;
}

Wenn Sie keine Standorte darstellen oder Entfernungen berechnen möchten, können Sie einen einfacheren Typ wie type: number verwenden. Wenn Sie sich einen Standort in einer Tabelle ansehen, wird der Wert aus Ihrer Datenbank angezeigt. Außerdem wird automatisch ein Link zu diesem Standort in Google Maps generiert:

Unterstützte Datenbankdialekte für location

Damit Looker type: location in Ihrem Looker-Projekt unterstützt, muss es auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle sehen Sie, welche Dialekte type: location in der neuesten Version von Looker unterstützen:

number

type: number wird mit Zahlen oder Ganzzahlen verwendet.

Der Parameter sql für type: number-Dimensionen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer Zahl oder Ganzzahl führt.

type: number-Felder können mit den Parametern value_format oder value_format_name formatiert werden.

Die folgende LookML-Datei erstellt beispielsweise ein Feld namens profit basierend auf den Feldern revenue und cost und zeigt es dann in einem Geldformat an (1.234,56 $):

dimension: profit {
  type: number
  sql: ${revenue} - ${cost} ;;
  value_format_name: usd
}

Eine Dimension kann nur arithmetisch für andere Dimensionen und nicht für Maße durchgeführt werden. Außerdem erhalten Nutzer in type: number-Dimensionen keine Vorschläge, selbst wenn sie zur Anzeige von ID-Nummern verwendet werden.

string

type: string wird normalerweise mit Feldern verwendet, die Buchstaben oder Sonderzeichen enthalten. Es kann auch mit Zahlenfeldern verwendet werden. Looker bietet jedoch bessere Funktionen für die Handhabung von Zahlen, wenn Sie stattdessen type: number verwenden.

Der Parameter sql für Dimensionen vom Typ type: string kann einen beliebigen gültigen SQL-Ausdruck verwenden.

Im folgenden LookML wird beispielsweise das Feld full_name durch Kombinieren eines Felds namens first_name und last_name erstellt:

dimension: full_name {
  type: string
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}

In diesem Beispiel könnte type: string weggelassen werden, da string der Standardwert für type ist.

tier

Sie können type: bin als Alias für type: tier verwenden. Beide Typen sind austauschbar.

type: tier wird in Verbindung mit dem Parameter tiers verwendet, um eine numerische Dimension in eine Reihe von Zahlenbereichen zu unterteilen. Sie können beispielsweise eine Dimension „Alter“ in verschiedene Altersgruppen einstufen. Sie können die Darstellung der Stufen in der Looker-UI mit dem Parameter style ändern.

Das Nutzungsmuster lautet:

view: view_name {
dimension: field_name {
Typ: tier
tiers: [numerischer_Wert, numerischer_Wert, ... ]
Stil: Intervall
sql: ${my_field_name}}}

Der Parameter sql für type: tier-Dimensionen kann jeden gültigen SQL-Ausdruck annehmen, der zu einer Zahl oder Ganzzahl führt.

Das obige Beispiel für das Alter könnte so aussehen:

dimension: age_tier {
  type: tier
  tiers: [0, 10, 20, 30, 40, 50, 60, 70, 80]
  style: classic # the default value, could be excluded
  sql: ${age} ;;
}

Wie dies in der Looker-Benutzeroberfläche aussehen würde, wird im Abschnitt style auf dieser Seite beschrieben.

Die Dimension „type: tier“ kann nicht in benutzerdefinierten Filtern verwendet werden.

style

Mit dem Parameter style können Sie ändern, wie Ebenen in der Looker-Benutzeroberfläche angezeigt werden. Auch wenn die Daten in den Beispielen unten nicht enthalten sind, gibt es in den Daten negative Zahlen. In der Anfangsstufe gibt es aber alle Zahlen von negativ unendlich bis 0. Es gibt vier mögliche Werte:

classic

style: classic ist die Standardeinstellung und sieht so aus:

  • Sie können diese Notation der Stufe so interpretieren:
    • T02 [10,20) ist der Bereich von 10 bis 20.
    • T09 [80,inf) ist der Bereich einschließlich 80 und bis unendlich.

interval

style: interval ähnelt style: classic, hat aber nicht die führenden TXX-Labels. Es sieht so aus:

integer

style: integer muss mit separaten Ganzzahlwerten (z. B. Alter) verwendet werden. Wenn Sie versuchen, zum Definieren der Stufen Nicht-Ganzzahlen zu verwenden, erhalten Sie eine Fehlermeldung. Dieser Stil sieht so aus:

relational

style: relational wird am besten mit fortlaufenden Zahlen (z. B. Dollar) verwendet und sieht so aus:

Sie können auch Stile mit value_format festlegen. Beispiel:

dimension: amount_tier {
  type: tier
  tiers: [0, 10, 20, 30, 40, 50, 60, 70, 80]
  style: integer
  sql: ${amount} ;;
  value_format: "$#,##0"
}

Dieses Beispiel würde zu Stufenlabels wie $10 to $19, $20 to $29 usw. führen.

Wichtige Punkte

Die Verwendung von tier in Verbindung mit der Dimensionsfüllung kann zu unerwarteten Stufen-Buckets führen.

Beispiel: Für die Dimension type: tier, Altersgruppe, werden Ebenen-Buckets für Unter 0 und 0 bis 9 angezeigt, wenn die Dimensionsausführung aktiviert ist. Die Daten enthalten jedoch keine Alterswerte für diese Buckets:

Wenn die Dimension „Ausführung“ für die Altersstufe deaktiviert ist, spiegeln die Buckets die in den Daten verfügbaren Alterswerte genauer wider:

Sie können diese Funktion aktivieren oder deaktivieren. Bewegen Sie dazu den Mauszeiger über den Namen der Dimension in „Erkunden“, klicken Sie auf das Zahnradsymbol auf Feldebene und wählen Sie entweder Aufgefüllte Werte entfernen aus oder aktivieren Sie Fehlende Werte eingeben.

time

type: time wird in Verbindung mit einem dimension_group und dem Parameter timeframes verwendet, um zeitbasierte Dimensionen zu erstellen. So können Sie beispielsweise ganz einfach eine Datums-, Wochen- und Monatsdimension auf der Basis einer einzelnen Zeitstempelspalte erstellen.

type: time funktioniert nur mit einem dimension_group und nicht mit einem normalen dimension. Sie können jedoch einzelne zeitbasierte Dimensionen angeben, wie in diesem Abschnitt unten beschrieben.

Informationen zu Dimensionsgruppen finden Sie auf der Dokumentationsseite zu den dimension_group-Parametern. Hier finden Sie auch Informationen zu den Parametern timeframes, convert_tz und datatype sowie Hinweise zu häufigen Problemen und Einschränkungen bei der Verwendung zeitbasierter Daten.

unquoted

type: unquoted wird nur mit parameter-Feldern verwendet. Der Typ unquoted ähnelt type: string, mit dem Unterschied, dass der Wert von parameter in Anführungszeichen gesetzt wird, wenn er in die {% parameter %}-Flüssigkeitsvariable eingefügt wird. Dies ist nützlich, wenn Sie Werte in SQL einfügen (z. B. Spalten- oder Tabellennamen), die nicht in Anführungszeichen gesetzt werden können, damit sie richtig funktionieren.

Wenn Sie Werte ohne Anführungszeichen direkt in SQL einfügen, können unerwünschte SQL-Aktionen entstehen. Zur Behebung dieses Problems sind die Parameterwerte von type: unquoted auf die Zeichen A bis Z und 0 bis 9 (ohne Leerzeichen oder andere Sonderzeichen) beschränkt.

Das folgende LookML erstellt beispielsweise ein parameter namens table_name, das einen Wert ohne Anführungszeichen erzeugt:

parameter: table_name {
  type: unquoted
}

yesno

type: yesno erstellt ein Feld, das angibt, ob etwas wahr oder falsch ist. In der Benutzeroberfläche von „Entdecken“ werden die Werte Ja und Nein angezeigt.

Der Parameter sql für eine type: yesno-Dimension verwendet einen gültigen SQL-Ausdruck, der als TRUE oder FALSE ausgewertet wird. Lautet die Bedingung TRUE, wird dem Nutzer Ja angezeigt, andernfalls Nein.

Der SQL-Ausdruck für type: yesno-Dimensionen darf keine Aggregationen enthalten. Das bedeutet, dass sie keine SQL-Aggregationen oder Verweise auf LookML-Messwerte enthalten darf. Wenn Sie ein yesno-Feld erstellen möchten, das eine SQL-Aggregation enthält oder auf einen LookML-Messwert verweist, verwenden Sie einen Messwert mit type: yesno und nicht mit einer Dimension.

Die folgende LookML-Datei erstellt beispielsweise ein Feld, das basierend auf dem Feld status angibt, ob eine Bestellung bezahlt wurde oder nicht:

dimension: is_order_paid {
  type: yesno
  sql: ${status} = 'paid' ;;
}

Wenn Sie auf ein type: yesno-Feld in einem anderen Feld verweisen möchten, behandeln Sie das type: yesno-Feld als booleschen Wert (als wäre das bereits ein richtiger oder falscher Wert). Beispiel:

dimension: is_big_order {
  type: yesno
  sql: ${order_size} = 'big' ;;
}
# This is correct
measure: total_boxes_needed {
  type: number
  sql: SUM(CASE WHEN ${is_big_order} THEN 2 ELSE 1 END) ;;
}
# This is NOT correct
measure: total_boxes_needed {
  type: number
  sql: SUM(CASE WHEN ${is_big_order} = 'Yes' THEN 2 ELSE 1 END) ;;
}

Wenn Sie type: yesno mit zeitbasierten Daten verwenden, gibt die Dimension yes zurück, wenn der Datetime-Wert einen Wert hat. Andernfalls wird no zurückgegeben.

zipcode

type: zipcode wird mit Postleitzahlendimensionen verwendet, die Sie in einer statischen Karte (Punkte) grafisch darstellen möchten. Verwenden Sie für statische Karten (Regionen) ein Bundesland- oder Länderfeld. Jede Dimension von type: zipcode erhält automatisch die map_layer_name von us_zipcode_tabulation_areas. Wenn Sie die Postleitzahlen nicht darstellen möchten, können Sie einen einfacheren Typ wie type: number verwenden.

Der Parameter sql für type: zipcode-Dimensionen kann jeden gültigen SQL-Ausdruck verwenden, der zu einer fünfstelligen US-amerikanischen Postleitzahl führt.

Zum Filtern nach der Dimension „Postleitzahl“ muss bei einigen Datenbankdialekten das Datenbankfeld, auf das die Dimension „Postleitzahl“ verweist, ein Feld vom Typ „Varchar“ oder „String“ sein. Ein Feld vom Typ „Ganzzahl“ ist nicht zulässig.

Beispiel:

dimension: zip {
  type: zipcode
  sql: ${TABLE}.zipcode ;;
}

Einzelne Zeit- und Datumstypen

In der Regel werden Datumsangaben als dimension_group verarbeitet, das type: time verwendet.

Sie können für jeden Zeitraum, den Sie einschließen möchten, ein eigenes Feld vom Typ dimension oder filter erstellen, anstatt alle in einem einzigen dimension_group zu generieren. Dies wird in der Regel vermieden, es sei denn, Sie haben in Ihrer Datenbank bereits vorab berechnete Zeitspalten oder möchten die Namenskonvention für den Looker ändern (z. B. ein Feld namens created_date_of_purchase anstelle von created_date).

Viele verschiedene zeit- und datumsbasierte Typen sind unten aufgeführt.

Hier ein Beispiel für diese dimension_group-Definition:

dimension_group: created {
  type: time
  timeframes: [week, month, year]
  sql: ${TABLE}.created_at ;;
}

Sie können dies als logische Entsprechung verwenden:

dimension: created_week {
  type: date_week
  sql: ${TABLE}.created_at ;;
}
dimension: created_month {
  type: date_month
  sql: ${TABLE}.created_at ;;
}
dimension: created_year {
  type: date_year
  sql: ${TABLE}.created_at ;;
}

Verfügbare zeitbasierte Typen

Die folgenden Typen werden im Parameter type einer einzelnen Dimension verwendet, um zeit- oder datumsbasierte Felder zu erstellen. Verwenden Sie diese Typen nicht mit dem Parameter timeframe, der auf der Dokumentationsseite zu dimension_group beschrieben ist.

Alle einzelnen Zeit- und Datumstypen benötigen einen Zeitstempel als Eingabe aus Ihrer Datenbank.

Besondere Typen

Typ Beschreibung Beispielausgabe
date_raw Der Rohwert aus Ihrer Datenbank ohne Umwandlung oder Zeitzonenkonvertierung wird nicht auf der Seite „Entdecken“ angezeigt. Dies ist in der Regel nicht erforderlich, außer bei Joins oder Zeitvergleichen. 2014-09-03 17:15:00 +0000

Zeittypen

Typ Beschreibung Beispielausgabe
date_time Datum/Uhrzeit des zugrunde liegenden Felds (einige SQL-Dialekte zeigen so viel Präzision an, wie Ihre Datenbank enthält, andere nur Sekunden) 2014-09-03 17:15:00
date_time_of_day Tageszeit 17:15
date_hour Datum/Uhrzeit wurde auf die nächste Stunde gekürzt 2014-09-03 17
date_hour_of_day Ganzzahl des Tages vom zugrunde liegenden Feld 17
date_hourX Teilt jeden Tag in Intervalle mit der angegebenen Anzahl an Stunden auf. Erklärung erforderlich, siehe unten Siehe unten
date_minute Datum/Uhrzeit wurde auf die nächste Minute gekürzt 2014-09-03 17:15
date_minuteX Teilt jede Stunde in Intervalle mit der angegebenen Anzahl von Minuten auf. Erklärung erforderlich, siehe unten Siehe unten
date_second Datum/Uhrzeit wurde auf die nächste Sekunde gekürzt 2014-09-03 17:15:00
date_millisecond Datum/Uhrzeit wurde auf die nächste Millisekunde gekürzt. Weitere Informationen zur Dialektunterstützung finden Sie im Abschnitt Dialektunterstützung für Millisekunden und Mikrosekunden. 2014-09-03 17:15:00.000
date_millisecondX Teilt jede Sekunde in Intervalle mit der angegebenen Anzahl von Millisekunden auf. Weitere Informationen zur Unterstützung von Dialekten finden Sie im Abschnitt Dialektunterstützung für Millisekunden und Mikrosekunden. 2014-09-01 01:00:00.250
date_microsecond Datum/Uhrzeit wurde auf die nächste Mikrosekunde gekürzt. Informationen zur Dialektunterstützung finden Sie im Abschnitt Dialektunterstützung für Millisekunden und Mikrosekunden. 2014-09-03 17:15:00.000000

Datumstypen

Typ Beschreibung Beispielausgabe
date Datum des zugrunde liegenden Felds 2017-09-03
date_date REMOVED 4.6 Ersetzt durch date

Wochentypen

Typ Beschreibung Beispielausgabe
date_week Datum der Woche, beginnend am Montag des zugrunde liegenden Datums und der Uhrzeit 2017-09-01
date_day_of_week Nur Wochentag Wednesday
date_day_of_week_index Wochentagindex (0 = Montag, 6 = Sonntag) 2

Beachten Sie, dass die Typen date_week, date_day_of_week und date_day_of_week_index vom Wert von week_start_day abhängen. Dies ist der Standardwert von Montag.

Monatstypen

Typ Beschreibung Beispielausgabe
date_month Jahr und Monat des zugrunde liegenden Datums und der Uhrzeit 2017-09
date_month_num Ganzzahl des Monats für das zugrunde liegende Datum 9
date_month_name Name des Monats September
date_day_of_month Tag des Monats 3
date_fiscal_month_num Ganzzahl des Monats für das zugrunde liegende Datum 9

Wenn Sie den Typ date_fiscal_month_num verwenden möchten, muss der Parameter fiscal_month_offset im Modell festgelegt werden.

Quartalstypen

Typ Beschreibung Beispielausgabe
date_quarter Jahr und Quartal des zugrunde liegenden Datums und der Uhrzeit 2017-Q3
date_quarter_of_year Quartal mit einem vorangestellten „Q“ Q3
date_fiscal_quarter Geschäftsjahr und -quartal des zugrunde liegenden Datums und der Uhrzeit 2017-Q3
date_fiscal_quarter_of_year Geschäftsquartal des Jahres mit vorangestelltem "Q" Q3

Wenn Sie die Typen date_fiscal_quarter und date_fiscal_quarter_of_year verwenden möchten, muss der Parameter fiscal_month_offset im Modell festgelegt werden.

Jahrstypen

Typ Beschreibung Beispielausgabe
date_year Ganzzahliges Jahr der zugrunde liegenden Datum-/Uhrzeit 2017
date_day_of_year Tag des Jahres 143
date_week_of_year Woche des Jahres als Zahl 17
date_fiscal_year Ganzzahliges Geschäftsjahr des zugrunde liegenden Datums und Uhrzeit 2017

Um den Typ date_fiscal_year zu verwenden, muss der Parameter fiscal_month_offset im Modell festgelegt werden.

date_hourX verwenden

In date_hourX wird X durch 2, 3, 4, 6, 8 oder 12 ersetzt.

Dadurch wird der Tag in Intervalle aufgeteilt, die der angegebenen Anzahl an Stunden entsprechen. date_hour6 wird beispielsweise jeden Tag in 6-Stunden-Segmente aufgeteilt, die so aussehen:

  • 2014-09-01 00:00:00
  • 2014-09-01 06:00:00
  • 2014-09-01 12:00:00
  • 2014-09-01 18:00:00

Eine Zeile mit einem time von 2014-09-01 08:03:17 hätte beispielsweise einen date_hour6 von 2014-09-01 06:00:00.

date_minuteX verwenden

In date_minuteX wird X durch 2, 3, 5, 10, 15 oder 30 ersetzt.

Damit wird jede Stunde in Intervalle aufgeteilt und die angegebene Anzahl von Minuten erreicht. date_minute15 wird beispielsweise jede Stunde in 15-Minuten-Segmente aufgeteilt. Das sieht dann so aus:

  • 2014-09-01 01:00:00
  • 2014-09-01 01:15:00
  • 2014-09-01 01:30:00
  • 2014-09-01 01:45:00

Beispiel: Eine Zeile mit einem time von 2014-09-01 01:17:35 hätte ein date_minute15 von 2014-09-01 01:15:00.

Zeitzonen und convert_tz

Im Allgemeinen funktionieren Zeitberechnungen (Unterschiede, Dauern usw.) nur dann richtig, wenn Sie mit Zeitwerten arbeiten, die alle in dieselbe Zeitzone umgewandelt werden. Daher sollten Sie beim Schreiben von LookML Zeitzonen berücksichtigen.

Looker bietet verschiedene Zeitzoneneinstellungen, mit denen zeitbasierte Daten zwischen verschiedenen Zeitzonen umgewandelt werden. Looker konvertiert standardmäßig Zeitzonen. Wenn Sie nicht möchten, dass Looker eine Zeitzone für eine bestimmte Dimension oder Dimensionsgruppe umwandelt, können Sie den Parameter convert_tz verwenden, der auf der Dokumentationsseite für den Parameter convert_tz beschrieben ist.

Dialektunterstützung für Millisekunden und Mikrosekunden

Looker unterstützt die Genauigkeit bis auf Mikrosekunden. Einige Datenbanken unterstützen jedoch eine Genauigkeit von nur Sekunden. Wenn eine Datenbank einen genaueren Zeittyp findet, als er unterstützt, wird sie auf Sekunden aufgerundet.

In der neuesten Version von Looker unterstützen die folgenden Dialekte Millisekunden:

In der neuesten Version von Looker unterstützen die folgenden Dialekte Mikrosekunden:

Einzelne Dauertypen

Dauer wird in der Regel als dimension_group behandelt, die type: duration verwendet.

Sie können ein dimension für jede einzelne Dauer erstellen, die Sie einschließen möchten, anstatt alle in einem einzigen dimension_group zu generieren. Dies wird normalerweise vermieden, es sei denn, Sie möchten die Namenskonvention von Looker ändern, z. B. ein Feld namens Number of Days to Delivery (Anzahl der Tage bis zur Lieferung) statt Duration to Delivery (Dauer bis zur Lieferung).

Weitere Informationen zu den einzelnen Dauertypen

Wenn Sie einen Zeitraumtyp für eine Dimension verwenden, müssen Sie auch die Parameter sql_start und sql_end angeben, um die Start- und Endzeiten für die Berechnung des Zeitunterschieds anzugeben.

Die Parameter sql_start und sql_end können einen beliebigen gültigen SQL-Ausdruck verwenden, der Daten im Format Zeitstempel, Datetime, Datum, Epoche oder jjjjmmtt enthält. Die Felder sql_start und sql_end können eines der folgenden Felder sein:

  • Ein Verweis auf einen raw-Zeitraum aus einer vorhandenen Dimensionsgruppe von type: time.
  • Ein Verweis auf eine Dimension von type: date_raw.
  • Ein SQL-Ausdruck, der ein Zeitstempel ist, z. B. ein Verweis auf eine SQL-Spalte, die ein Zeitstempel ist.
  • Ein SQL-Ausdruck, der eine Zeit aus Ihrer Datenbank mit dem entsprechenden Ausdruck für Ihren Dialekt abruft.

Hier ein Beispiel für diese dimension_group-Definition:

dimension_group: to_delivery {
  type: duration
  intervals: [day, hour]
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

Sie können diese dimension-Parameter als logische Entsprechung verwenden:

dimension: number_of_days_to_delivery {
  type: duration_day
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

dimension: number_of_hours_to_delivery {
  type: duration_hour
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

In der Benutzeroberfläche von „Erkunden“ werden die Dimensionen Anzahl der Tage bis zur Auslieferung und Anzahl der Stunden bis zur Auslieferung erstellt.

Verfügbare Dauertypen

Die folgenden Typen werden im Parameter type einer einzelnen Dimension verwendet, um dauerbasierte Felder zu erstellen. Verwenden Sie diese Typen nicht mit dem Parameter intervals, der auf der Dokumentationsseite zu dimension_group beschrieben ist.

Alle einzelnen Dauertypen erfordern einen Zeitstempel als Eingabe aus Ihrer Datenbank.

Typ Beschreibung Beispielausgabe
duration_day Berechnet einen Zeitunterschied in Tagen. 9 days
duration_hour Zeitunterschied in Stunden berechnen 171 hours
duration_minute Berechnet einen Zeitunterschied in Minuten. 10,305 minutes
duration_month Berechnet eine Zeitdifferenz in Monaten. 3 months
duration_quarter Berechnet eine Zeitdifferenz in Quartalen des Jahres 2 quarters
duration_second Berechnet einen Zeitunterschied in Sekunden. 606,770 seconds
duration_week Berechnet einen Zeitunterschied in Wochen 6 weeks
duration_year Berechnet einen Zeitunterschied in Jahren. 2 years