Nutzung
explore: explore_name {
join: view_name { ... }
}
|
Hierarchie
join |
Standardwert
Keine
Akzeptiert
Der Name einer vorhandenen Ansicht
Sonderregeln
|
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
explorebestimmt die Tabelle in derFROM-Anweisung der generierten SQL-Abfrage. - Jeder
join-Parameter bestimmt eineJOIN-Klausel der generierten SQL-Abfrage.- Der Parameter
typebestimmt den Typ des SQL-Joins. - Die Parameter
sql_onundforeign_keybestimmen dieON-Klausel der generierten SQL-Abfrage.
- Der Parameter
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.