You are viewing documentation for Looker 25.20. Click this link to see the most recent documentation.

zusammenführen

Nutzung


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

Hierarchie

Model File

explore

join

Standardwert

Keine

Akzeptiert

Der Name einer vorhandenen Ansicht

Besondere Regeln

Für diesen Parameter ist ein Ansichtsname zulässig, nicht der Name der zugrunde liegenden Tabelle der Ansicht (obwohl diese oft identisch sind).
Wenn Ihr Dialekt symmetric_aggregates nicht unterstützt, werden die meisten Messwerttypen aus verknüpften Ansichten ausgeschlossen.
Sie können dieselbe Ansicht mit from mehrmals 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 beliebig viele Ansichten für ein bestimmtes Explore verknüpfen.

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 dem Explore zugeordnete Tabelle wird in die FROM-Anweisung des von Looker generierten SQL-Codes eingefügt. Tabellen, die mit verknüpften Ansichten verknüpft sind, werden in die JOIN-Anweisung des von Looker generierten SQL-Codes eingefügt.

Wichtige Join-Parameter

Um die Join-Beziehung (die SQL-ON-Klausel) zwischen einem Explore und einer Ansicht zu definieren, 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.

Sie müssen auch darauf achten, dass Sie die richtigen Join-Typen und Beziehungen verwenden. Die Parameter type und relationship sind jedoch nicht immer explizit erforderlich. Wenn die Standardwerte type: left_outer und relationship: many_to_one für Ihren Anwendungsfall geeignet sind, können diese Parameter ausgeschlossen werden.

Diese wichtigen Parameter und ihre Beziehung zum SQL-Code, den Looker generiert, lassen sich so zusammenfassen:

Der Parameter explore bestimmt die Tabelle in der FROM-Anweisung der generierten SQL-Abfrage.
Jeder join-Parameter bestimmt eine JOIN-Anweisung 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-Anweisung ON direkt schreiben. Damit lassen sich dieselben Joins wie mit foreign_key ausführen, aber der Code ist leichter zu lesen und zu verstehen.

Weitere Informationen finden Sie auf der Dokumentationsseite zu sql_on-Parametern.

`foreign_key`

Mit foreign_key können Sie eine Join-Beziehung mithilfe des Primärschlüssels der verbundenen Ansicht herstellen und sie mit einer Dimension im Explore verbinden. Dieses Muster ist im Datenbankdesign sehr häufig und foreign_key ist eine elegante Möglichkeit, den Join in diesen Fällen auszudrücken.

Weitere Informationen finden Sie auf der Dokumentationsseite für den Parameter foreign_key.

`type`

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

Eine ausführliche Erklärung finden Sie auf der Dokumentationsseite zum Parameter type.

`relationship`

relationship hat keine direkten Auswirkungen auf den von Looker generierten SQL-Code, ist aber entscheidend für das ordnungsgemäße Funktionieren von Looker. Wenn Sie nicht explizit 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 und Joins mit anderen Beziehungen müssen richtig deklariert werden.

Weitere Informationen finden Sie auf der Dokumentationsseite für den Parameter relationship.

Beispiele

Verbinden Sie die Ansicht mit dem Namen customer mit dem Explore mit dem Namen 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
  }
}

Verbinden Sie die Ansicht mit dem Namen address mit dem Explore mit dem Namen 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
  }
}

Verbinden Sie die Ansicht mit dem Namen member mit dem Explore mit dem Namen 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 zugrunde liegende Tabellennamen verwenden

Für den Parameter join ist nur ein Ansichtsname zulässig, nicht der mit dieser Ansicht verknüpfte Tabellenname. 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 Messungen sind symmetrische Summen erforderlich

Wenn Sie keine symmetrischen Summen verwenden, sind die meisten Messwerttypen von Ansichten mit Joins ausgeschlossen. Damit Looker symmetrische Summen 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 Summen 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+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
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+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
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
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 1:1 sind, zu ungenauen Ergebnissen in Aggregatfunktionen führen. Da Looker-Messwerte Aggregatfunktionen sind, werden nur Messwerte von type: count (als COUNT DISTINCT) aus verknüpften Ansichten in das Explore übernommen. Wenn Sie eine 1:1-Join-Beziehung haben, können Sie den Parameter relationship verwenden, um die Einbeziehung der anderen Messwerttypen zu erzwingen:

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

Die Gründe dafür, dass Looker so funktioniert (für Dialekte, die keine symmetrischen Summen unterstützen), werden im Communitybeitrag The problem of SQL fanouts (Das Problem von SQL-Fanouts) ausführlicher erläutert.

Wichtige Punkte

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

Wenn eine einzelne Tabelle verschiedene Arten von Entitäten enthält, kann eine Ansicht mehr als einmal mit einem Explore verknüpft werden. Dazu müssen Sie den Parameter from verwenden. Angenommen, Sie haben einen order-Explore und müssen ihn zweimal mit einer person-Ansicht 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

In Looker wird für Joins nach Möglichkeit LEFT JOIN verwendet. Wenn Sie etwas in dieser Art 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 einen Explore erstellt, in dem nur Ereignisse im Zusammenhang mit bekannten Mitgliedern berücksichtigt werden. Die bevorzugte Methode, dies in Looker auszuführen, ist jedoch die Verwendung von LEFT JOIN, um Ereignis- und Mitgliedsdaten zusammenzufügen:

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 Mitgliedereignisse sehen möchten:

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 nicht erzwungen, dass sie sich nur Mitgliederereignisse ansehen, indem Sie den Join verwenden.

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

Dieser Abschnitt gilt nur für Datenbankdialekte, die symmetrische Aggregationen nicht unterstützen. Im Abschnitt Häufige Probleme auf dieser Seite finden Sie Informationen dazu, ob Ihr Dialekt symmetrische Summen unterstützt.

Wenn Ihr Datenbankdialekt symmetrische Summen nicht unterstützt, sollten Sie Joins vermeiden, die zu einem Fanout führen. Joins mit einer 1-zu-N-Beziehung zwischen dem Explore und der Ansicht sollten also generell vermieden werden. Fassen Sie stattdessen die Daten aus der Ansicht in einer abgeleiteten Tabelle zusammen, um eine 1:1-Beziehung zum Explore herzustellen, und binden Sie diese abgeleitete Tabelle dann in das Explore ein.

Dieses wichtige Konzept wird im Communitybeitrag The problem of SQL fanouts (Das Problem von SQL-Fanouts) näher erläutert.

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