zusammenführen

Nutzung

Explore: Name_Erkunden {
join: view_name { ... }
}

Hierarchie Modelldatei explore join

Standardwert Keine Akzeptiert Name einer vorhandenen Ansicht Sonderregeln Für diesen Parameter ist ein Ansichtsname zulässig, nicht der Name der zugrunde liegenden Tabelle (obwohl sie häufig identisch sind). Wenn Ihr Dialekt symmetric_aggregates nicht unterstützt, werden die meisten Maßeinheiten aus verknüpften Ansichten ausgeschlossen Mit from können Sie derselben Ansicht mehrmals beitreten.

Definition

Mit join können Sie die Join-Beziehung zwischen einer Erkundung und einer Ansicht definieren, sodass Sie Daten aus mehreren Ansichten kombinieren können. Du kannst an jeder Erkundung beliebig viele Aufrufe teilen.

Jede Ansicht ist einer Tabelle in Ihrer Datenbank oder einer abgeleiteten Tabelle zugeordnet, die Sie in Looker definiert haben. Da eine explorative Datenanalyse mit einer Ansicht verknüpft ist, ist sie ebenfalls mit einer Tabelle verbunden.

Die mit der Funktion „Erkunden“ verknüpfte Tabelle wird in der Klausel FROM des von Looker generierten SQL-Codes gespeichert. Tabellen, die mit verknüpften Ansichten verknüpft sind, werden in die Klausel JOIN des von Looker generierten SQL-Eintrags eingefügt.

Wichtige Join-Parameter

Zum Definieren der Join-Beziehung (die SQL-ON-Klausel) zwischen einem Explore und einer Ansicht müssen Sie join in Kombination mit anderen Parametern verwenden.

Zum Einrichten der SQL-Klausel ON muss entweder der Parameter sql_on oder der Parameter foreign_key verwendet werden.

Außerdem musst du dafür sorgen, dass du geeignete Join-Typen und -Beziehungen verwendest, obwohl 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 ausgeschlossen werden.

Diese Schlüsselparameter und ihre Beziehung zum von Looker generierten SQL werden hier gezeigt:

sql_on

Mit sql_on können Sie eine Join-Beziehung herstellen, indem Sie die SQL-Klausel ON direkt schreiben. Sie kann dieselben Joins durchführen wie foreign_key, aber sie 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 verknüpften Ansicht verwenden und ihn mit einer Dimension auf dem Tab „Erkunden“ verbinden. Dieses Muster ist im Datenbankdesign sehr geläufig und foreign_key ist eine elegante Möglichkeit, den Join in diesen Fällen auszudrücken.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter foreign_key.

type

Die meisten Joins in Looker sind LEFT JOIN aus den im Abschnitt Nach Möglichkeit nicht in Joins anwenden genannten Gründen auf dieser Seite. Wenn Sie also kein type hinzufügen, geht Looker davon aus, dass Sie ein LEFT JOIN wünschen. Wenn Sie aus einem anderen Grund eine andere Join-Methode benötigen, können Sie dies mit type tun.

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

relationship

Im Diagramm oben hat relationship keine direkten Auswirkungen auf SQL, das von Looker generiert wird, aber für die ordnungsgemäße Funktionsweise von Looker ist es entscheidend. Wenn Sie nicht explizit einen relationship hinzufügen, geht Looker davon aus, dass es many-to-one ist. Das bedeutet, dass viele Zeilen im explorativen Analysetool eine Zeile in der verknüpften Ansicht enthalten können. Nicht alle Joins haben diese Art von Beziehung. Joins mit anderen Beziehungen müssen ordnungsgemäß deklariert werden.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter relationship.

Beispiele

Die Ansicht „customer“ mit der Funktion „Erkunden“ (order) verknüpfen, in der sich die Join-Beziehung befindet

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
  }
}

-

Die Ansicht „address“ mit der Funktion „Erkunden“ (person) verknüpfen, in der sich die Join-Beziehung befindet

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
  }
}

-

Die Ansicht „member“ mit der Funktion „Erkunden“ (event) verknüpfen, in der sich die Join-Beziehung befindet

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 keine zugrunde liegenden Tabellennamen verwenden

Für den Parameter join wird nur der Ansichtsname verwendet, nicht der mit dieser Ansicht verknüpfte Tabellenname. Häufig sind der Ansichts- und der Tabellenname identisch. Dies kann zu der falschen Schlussfolgerung führen, dass Tabellennamen verwendet werden können.

Für einige Maßnahmen sind symmetrische Aggregate erforderlich

Wenn Sie keine symmetrischen Zusammenfassungen verwenden, werden die meisten Messwerttypen aus verknüpften Ansichten ausgeschlossen. Damit Looker in Ihrem Looker-Projekt symmetrische Aggregate unterstützt, muss sie auch Ihr Datenbankdialekt unterstützen. Die folgende Tabelle zeigt, welche Dialekte in der neuesten Version von Looker symmetrische Aggregate unterstützen:

Ohne symmetrische Aggregationen können Join-Beziehungen, die nicht 1:1-Beziehungen sind, zu ungenauen Ergebnissen in Aggregatfunktionen führen. Da die Looker-Messwerte zusammengefasste Funktionen sind, werden nur Messwerte von type: count (als COUNT DISTINCT) aus verknüpften Ansichten in die Ansicht „Erkunden“ aufgenommen. Wenn Sie eine 1:1-Join-Beziehung haben, können Sie den Parameter relationship verwenden, um die Aufnahme der anderen Messwerttypen zu erzwingen. Beispiel:

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

Die Gründe, warum Looker auf diese Weise funktioniert (für Dialekte, die keine symmetrischen Aggregationen unterstützen), werden im Hilfeartikel Probleme mit SQL-Fanouts ausführlicher beschrieben.

Wichtige Informationen

Mit from können Sie dieselbe Tabelle mehrmals zusammenführen.

Wenn eine einzelne Tabelle unterschiedliche Arten von Elementen enthält, ist es möglich, eine Ansicht mehrmals mit dem Bereich „Erkunden“ zu verknüpfen. Dazu müssen Sie den Parameter from verwenden. Angenommen, Sie haben eine order-Anfrage und müssen einer person-Ansicht zweimal beitreten: 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} ;;
  }
}

Verwenden Sie nach Möglichkeit keine Geschäftslogik in Joins.

Der Standardansatz von Looker besteht darin, nach Möglichkeit ein LEFT JOIN zu verwenden. Ziehen Sie einen anderen Ansatz in Betracht, wenn Sie in dieser Hinsicht etwas tun:

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 den Modus „Erkunden“ erstellt, der nur Ereignisse berücksichtigt, die bekannten Mitgliedern zugeordnet sind. Die bevorzugte Methode für die Ausführung in Looker wäre jedoch die Verwendung von LEFT JOIN, um Ereignisdaten und Mitgliederdaten einfach folgendermaßen in Verbindung zu halten:

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

-

Dann erstellen Sie eine Dimension, die auf yes oder no gesetzt werden kann, wenn Sie nur Mitgliederereignisse wie die folgenden sehen möchten:

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

-

Dieser Ansatz ist zu bevorzugen, da Nutzer so flexibel alle Ereignisse oder nur Mitgliederereignisse ansehen können. Du hast sie nicht gezwungen, nur über den Join nur auf Mitgliederveranstaltungen zuzugreifen.

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 Probleme auf dieser Seite können Sie nachlesen, ob Ihr Dialekt symmetrische Aggregationen unterstützt.

Wenn Ihr Datenbankdialekt keine symmetrischen Aggregate unterstützt, sollten Sie Joins vermeiden, die zu einem Fanout führen. Joins mit einer 1:n-Beziehung zwischen „Erkunden“ und „Ansicht“ sollten also vermieden werden. Aggregieren Sie stattdessen die Daten aus der Ansicht in einer abgeleiteten Tabelle, um eine 1:1-Beziehung mit dem Tab „Entdecken“ herzustellen, und verknüpfen Sie diese abgeleitete Tabelle dann mit dem Tab „Erkunden“.

Dieses wichtige Konzept wird im Hilfeartikel Probleme mit SQL-Fanouts näher erläutert.