Sie sehen sich die Dokumentation für Looker 26.20 an. Klicken Sie auf diesen Link, um die aktuelle Dokumentation aufzurufen.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

zusammenführen

Nutzung


explore: explore_name {
  join: view_name { ... }
}

Hierarchie

Modell-Datei

explore

join

Standardwert

Keine

Akzeptiert

Der Name einer vorhandenen Ansicht

Sonderregeln

Dieser Parameter akzeptiert einen Ansichtsnamen, nicht den Namen der zugrunde liegenden Tabelle der Ansicht (obwohl diese oft identisch sind).
Wenn Ihr Dialekt symmetric_aggregates nicht unterstützt, werden die meisten Measure-Typen aus verknüpften Ansichten ausgeschlossen.
Sie können dieselbe Ansicht mehrmals mit from verbinden.

Definition

Mit join können Sie die Join-Beziehung zwischen einem Explore und einer Ansicht definieren, um Daten aus mehreren Ansichten zu kombinieren. Sie können für ein bestimmtes Explore beliebig viele Ansichten verknüpfen.

Zur Erinnerung: Jede Ansicht ist mit einer Tabelle in Ihrer Datenbank oder einer abgeleiteten Tabelle verknüpft, die Sie in Looker definiert haben. Da ein Explore mit einer Ansicht verknüpft ist, ist es auch mit einer Tabelle verbunden.

Die mit dem Explore verknüpfte Tabelle wird in die FROM-Klausel des von Looker generierten SQL-Codes eingefügt. Tabellen, die mit verknüpften Ansichten verknüpft sind, werden in die JOIN-Klausel des von Looker generierten SQL-Codes eingefügt.

Wichtige Join-Parameter

Wenn Sie die Join-Beziehung (die SQL-ON-Klausel) zwischen einem Explore und einer Ansicht definieren möchten, müssen Sie join in Kombination mit anderen Parametern verwenden.

Sie müssen entweder den Parameter sql_on oder den Parameter foreign_key verwenden, um die SQL-ON-Klausel zu erstellen.

Außerdem müssen Sie die richtigen Join-Typen und Beziehungen verwenden, auch wenn die Parameter type und relationship nicht immer explizit erforderlich sind. Wenn die Standardwerte type: left_outer und relationship: many_to_one für Ihren Anwendungsfall geeignet sind, können diese Parameter weggelassen werden.

Diese Schlüsselparameter und ihre Beziehung zu dem von Looker generierten SQL-Code lassen sich so zusammenfassen:

Der Parameter explore bestimmt die Tabelle in der FROM-Anweisung der generierten SQL-Abfrage.
Jeder join-Parameter bestimmt eine JOIN-Klausel der generierten SQL-Abfrage.
- Der Parameter type bestimmt den Typ des SQL-Joins.
- Die Parameter sql_on und foreign_key bestimmen die ON-Klausel der generierten SQL-Abfrage.

`sql_on`

Mit sql_on können Sie eine Join-Beziehung herstellen, indem Sie die SQL-ON-Klausel direkt schreiben. Damit können dieselben Joins wie mit foreign_key erstellt werden, aber die Syntax ist leichter zu lesen und zu verstehen.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter sql_on.

`foreign_key`

Mit foreign_key können Sie eine Join-Beziehung herstellen, indem Sie den Primärschlüssel der verbundenen Ansicht verwenden und ihn mit einer Dimension im Explore verbinden. Dieses Muster ist im Datenbankdesign sehr verbreitet und foreign_key ist eine elegante Möglichkeit, den Join in diesen Fällen auszudrücken.

Ausführliche Informationen finden Sie auf der Dokumentationsseite zum Parameter foreign_key.

`type`

Die meisten Joins in Looker sind LEFT JOIN. Die Gründe dafür werden im Abschnitt Nach Möglichkeit keine Geschäftslogik in Joins anwenden auf dieser Seite erläutert. Wenn Sie also nicht explizit einen type hinzufügen, geht Looker davon aus, dass Sie einen LEFT JOIN möchten. Wenn Sie jedoch aus irgendeinem Grund einen anderen Join-Typ benötigen, können Sie type verwenden.

Eine vollständige Erläuterung finden Sie auf der Dokumentationsseite zum Parameter type.

`relationship`

relationship hat keine direkten Auswirkungen auf das von Looker generierte SQL, ist aber entscheidend für die ordnungsgemäße Funktion von Looker. Wenn Sie nicht explizit eine relationship hinzufügen, interpretiert Looker die Beziehung als many-to-one. Das bedeutet, dass viele Zeilen im Explore eine Zeile in der verknüpften Ansicht haben können. Nicht alle Joins haben diese Art von Beziehung. Joins mit anderen Beziehungen müssen ordnungsgemäß deklariert werden.

Ausführliche Informationen finden Sie auf der Dokumentationsseite zum Parameter relationship.

Beispiele

Verknüpfen Sie die Ansicht customer mit dem Explore order, wobei die Join-Beziehung

FROM order LEFT JOIN customer ON order.customer_id = customer.id:

explore: order {
  join: customer {
    foreign_key: customer_id
    relationship: many_to_one # Could be excluded since many_to_one is the default
    type: left_outer          # Could be excluded since left_outer is the default
  }
}

Verknüpfen Sie die Ansicht address mit dem Explore person, wobei die Join-Beziehung

FROM person LEFT JOIN address ON person.id = address.person_id AND address.type = 'permanent':

explore: person {
  join: address {
    sql_on: ${person.id} = ${address.person_id} AND ${address.type} = 'permanent' ;;
    relationship: one_to_many
    type: left_outer # Could be excluded since left_outer is the default
  }
}

Verknüpfen Sie die Ansicht member mit dem Explore event, wobei die Join-Beziehung

FROM event INNER JOIN member ON member.id = event.member_id:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    relationship: many_to_one # Could be excluded since many_to_one is the default
    type: inner
  }
}

Häufige Herausforderungen

`join` muss Ansichtsnamen und nicht die Namen der zugrunde liegenden Tabellen verwenden

Der Parameter join akzeptiert nur einen Ansichtsnamen, nicht den Tabellennamen, der dieser Ansicht zugeordnet ist. Häufig sind der Ansichtsname und der Tabellenname identisch, was zu dem falschen Schluss führen kann, dass Tabellennamen verwendet werden können.

Für einige Arten von Measures sind symmetrische Aggregate erforderlich.

Wenn Sie keine symmetrischen Aggregate verwenden, werden die meisten Measure-Typen aus verknüpften Ansichten ausgeschlossen. Damit Looker symmetrische Aggregate in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle ist zu sehen, welche Dialekte symmetrische Aggregate in der aktuellen Looker-Version unterstützen:

Dialekt	Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Ohne symmetrische Aggregate können Join-Beziehungen, die nicht eins zu eins sind, zu ungenauen Ergebnissen in Aggregatfunktionen führen. Da Looker-Measures Aggregatfunktionen sind, werden nur Measures vom Typ type: count (als COUNT DISTINCT) aus verknüpften Ansichten in das Explore übernommen. Wenn Sie eine 1:1-Join-Beziehung haben, können Sie mit dem Parameter relationship erzwingen, dass die anderen Messwerttypen einbezogen werden, z. B. so:

explore: person {
  join: dna {
    sql_on: ${person.dna_id} = ${dna.id} ;;
    relationship: one_to_one
  }
}

Die Gründe, warum Looker so funktioniert (für Dialekte, die keine symmetrischen Aggregate unterstützen), werden im Community-Beitrag The problem of SQL fanouts ausführlicher erläutert.

Wichtige Punkte

Sie können dieselbe Tabelle mehrmals mit `from` verknüpfen.

Wenn eine einzelne Tabelle verschiedene Arten von Entitäten enthält, kann eine Ansicht mehrmals mit einem Explore verknüpft werden. Dazu müssen Sie den Parameter from verwenden. Angenommen, Sie haben ein Explore order und müssen die Ansicht person zweimal damit verknüpfen: einmal für den Kunden und einmal für den Kundenservicemitarbeiter. Das könnte dann folgendermaßen aussehen:

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
  join: representative {
    from: person
    sql_on: ${order.representative_id} = ${representative.id} ;;
  }
}

Geschäftslogik nach Möglichkeit nicht in Joins anwenden

Der Standardansatz von Looker für Joins besteht darin, nach Möglichkeit einen LEFT JOIN zu verwenden. Wenn Sie etwas Ähnliches tun, sollten Sie einen anderen Ansatz in Betracht ziehen:

explore: member_event {
  from: event
  always_join: [member]
  join: member {
    sql_on: ${member_event.member_id} = ${member.id} ;;
    type: inner
  }
}

In diesem Beispiel haben wir ein Explore erstellt, das sich nur Ereignisse ansieht, die mit bekannten Mitgliedern verknüpft sind. In Looker ist es jedoch besser, einen LEFT JOIN zu verwenden, um Ereignisdaten und Mitgliedsdaten zusammenzuführen, wie hier:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
  }
}

Anschließend erstellen Sie eine Dimension, die Sie auf yes oder no festlegen können, wenn Sie nur Ereignisse für Mitglieder sehen möchten, z. B.:

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

Dieser Ansatz ist vorzuziehen, da Nutzer so die Möglichkeit haben, sich entweder alle Ereignisse oder nur Mitgliederereignisse anzusehen. Sie haben sie nicht gezwungen, sich nur die Mitgliedereignisse über den Join anzusehen.

Wenn Sie keine symmetrischen Aggregate verwenden, vermeiden Sie Joins, die Fanouts verursachen.

Dieser Abschnitt gilt nur für Datenbankdialekte, die keine symmetrischen Aggregate unterstützen. Im Abschnitt Häufige Herausforderungen auf dieser Seite finden Sie Informationen dazu, ob Ihr Dialekt symmetrische Aggregate unterstützt.

Wenn Ihr Datenbankdialekt keine symmetrischen Aggregate unterstützt, sollten Sie Joins vermeiden, die zu einem Fanout führen. Mit anderen Worten: Joins mit einer 1:n-Beziehung zwischen dem Explore und der Ansicht sollten im Allgemeinen vermieden werden. Fassen Sie stattdessen die Daten aus der Ansicht in einer abgeleiteten Tabelle zusammen, um eine Eins-zu-eins-Beziehung mit dem Explore herzustellen, und binden Sie diese abgeleitete Tabelle dann in das Explore ein.

Dieses wichtige Konzept wird im Community-Beitrag The problem of SQL fanouts näher erläutert.

zusammenführen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.