Diese Seite richtet sich an alle, die LookML zum Erstellen eines Explores in Looker verwenden möchten. Die Seite ist einfacher zu verstehen, wenn Sie mit SQL vertraut sind, insbesondere wenn Sie den Unterschied zwischen inneren und äußeren Joins verstehen. Eine kurze Erläuterung der Unterschiede zwischen inneren und äußeren Joins finden Sie im w3schools-Artikel zu SQL-Joins.
Looker kann zu einer leistungsfähigen SQL-Engine für Ihr Unternehmen werden. Die abstrakte Modellierung in LookML ermöglicht es Daten- und IT-Teams, allgemeine Regeln zu erstellen, die immer gelten. So können Geschäftsanalysten in der Wildnis Abfragen erstellen, die immer korrekt sind, selbst wenn das Datenteam nie mit einem Bedarf gerechnet hatte. Der wichtigste Motor für diese Funktion ist der Algorithmus für symmetrische Summen, der ein branchenweites Problem mit SQL-Joins löst. Damit der Algorithmus genutzt werden kann, müssen jedoch zwei Schritte richtig ausgeführt werden: Primärschlüssel müssen in jeder Ansicht korrekt sein, die einen Messwert enthält (in der Regel alle). Die relationship-Parameter müssen in jedem Join korrekt sein.
Primärschlüssel
In vielerlei Hinsicht ist das Verständnis des Primärschlüssels einer Tabelle im Wesentlichen dasselbe wie das Verständnis der Tabelle und der möglichen Aktionen. Die einzige Voraussetzung ist, dass die Spalte (oder der Satz verketteter Spalten), den Sie als Primärschlüssel auswählen, keine wiederholten Werte enthalten darf.
Der Parameter relationship
Nachdem Sie die Primärschlüssel bestätigt haben, können Sie den richtigen Wert für den Parameter relationship des Joins ermitteln. Der Parameter relationship teilt Looker mit, ob symmetrische Summen aufgerufen werden sollen, wenn der Join in eine SQL-Abfrage geschrieben wird. Ein möglicher Ansatz wäre hier, Looker anzuweisen, sie immer aufzurufen, wodurch immer genaue Ergebnisse erzeugt werden. Da dies jedoch zu Leistungseinbußen führt, sollten Sie symmetrische Summen mit Bedacht einsetzen.
Der Vorgang zur Bestimmung des richtigen Werts unterscheidet sich bei inneren und äußeren Joins geringfügig.
Innere Joins
Angenommen, Sie haben eine Tabelle mit Bestellungen mit dem Primärschlüssel order_id:
| order_id | Menge | customer_id |
|---|---|---|
| 1 | $25.00 | 1 |
| 2 | $50.00 | 1 |
| 3 | $75.00 | 2 |
| 4 | $35.00 | 3 |
Angenommen, Sie haben auch eine Tabelle mit Kunden mit dem Primärschlüssel customer_id:
| customer_id | first_name | last_name | Besuche |
|---|---|---|---|
| 1 | Amelia | Ohrhart | 2 |
| 2 | Logo: Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
Sie können diese Tabellen im Feld customer_id zusammenführen, das in beiden Tabellen vorhanden ist. Dieser Join wird in LookML so dargestellt:
explore: orders {
join: customers {
type: inner
sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
relationship: many_to_one
}
}
Das Ergebnis dieses LookML-Join kann wie folgt als einzelne verknüpfte Tabelle dargestellt werden:
| order_id | Menge | customer_id | customer_id | first_name | last_name | Besuche |
|---|---|---|---|---|---|---|
| 1 | $25.00 | 1 | 1 | Amelia | Ohrhart | 2 |
| 2 | $50.00 | 1 | 1 | Amelia | Ohrhart | 2 |
| 3 | $75.00 | 2 | 2 | Logo: Bessie | Coleman | 2 |
| 4 | $35.00 | 3 | 3 | Wilbur | Wright | 4 |
Die many_to_one-Beziehung bezieht sich hier darauf, wie oft ein Wert des Join-Felds (customer_id) in jeder Tabelle dargestellt wird. In der Tabelle orders (linke Tabelle) wird eine einzelne Kundennummer mehrmals dargestellt (in diesem Fall der Kunde mit der ID 1, die in mehreren Zeilen vorhanden ist).
In der Tabelle customers (rechts Tabelle) wird jede Kundennummer nur einmal dargestellt, da customer_id der Primärschlüssel dieser Tabelle ist. Daher können Datensätze in der Tabelle orders viele Übereinstimmungen für einen einzelnen Wert in der Tabelle customers enthalten. Wenn customer_id nicht in jeder Zeile der Tabelle customers eindeutig wäre, wäre die Beziehung many_to_many.
So können Sie den richtigen Beziehungswert programmatisch ermitteln, indem Sie die Primärschlüssel prüfen:
- Schreiben Sie zuerst
many_to_manyals Beziehung. Solange Ihre Primärschlüssel korrekt sind, liefert dies immer genaue Ergebnisse, da Looker immer den symmetrischen Aggregationsalgorithmus auslöst und die Genauigkeit erzwingt. Da der Algorithmus Abfragen jedoch komplizierter macht und die Laufzeit verlängert, ist es sinnvoll, eine oder beide Seiten inonestatt inmanyzu ändern. - Sehen Sie sich das Feld oder die Felder in der
sql_on-Klausel aus der linken Tabelle an. Wenn das Feld oder die Felder den Primärschlüssel der linken Tabelle bilden, können Sie die linke Seite desrelationship-Parameters inoneändern. Andernfalls mussmanybeibehalten werden. Informationen zu Sonderfällen finden Sie im Abschnitt Wichtige Hinweise weiter unten auf dieser Seite. - Sehen Sie sich als Nächstes das Feld oder die Felder an, die Ihre rechte Tabelle in der
sql_on-Klausel darstellen. Wenn das Feld oder die Felder den Primärschlüssel der rechten Tabelle bilden, können Sie die rechte Seite inoneändern.
Es empfiehlt sich, die sql_on-Wortgruppe mit der linken Tabelle, die auf der linken Seite des Gleichheitszeichens dargestellt wird, und der rechten Tabelle, also auf der rechten Seite, zu schreiben. Die Reihenfolge der Bedingungen im Parameter sql_on spielt keine Rolle, es sei denn, die Reihenfolge ist für den SQL-Dialekt Ihrer Datenbank relevant. Obwohl es für den sql_on-Parameter nicht erforderlich ist, dass Sie die Felder auf diese Weise anordnen, können Sie die Beziehung besser bestimmen, wenn Sie die sql_on-Bedingungen so anordnen, dass die linke und rechte Seite des Gleichheitszeichens mit der Methode übereinstimmt, die der relationship-Parameter von links nach rechts gelesen wird. Wenn Sie die Felder auf diese Weise anordnen, lässt sich außerdem leichter auf einen Blick erkennen, mit welcher vorhandenen Tabelle im Explore Sie die neue Tabelle verknüpfen.
Outer Joins
Bei Outer Joins müssen Sie auch berücksichtigen, dass ein Fanout auftreten kann, wenn während des Joins Null-Datensätze hinzugefügt werden. Das ist besonders wichtig, da Left Outer Joins der Standard in Looker sind. Null-Datensätze haben zwar keine Auswirkungen auf Summen oder Durchschnittswerte, beeinflussen aber die Art und Weise, wie Looker die Messung type: count ausführt. Wird dies nicht korrekt vorgenommen, werden die Null-Datensätze gezählt (was unerwünscht ist).
Bei einem Full Outer Join können Null-Datensätze zu jeder Tabelle hinzugefügt werden, wenn im Join-Schlüssel Werte fehlen, die in der anderen Tabelle vorhanden sind. Das wird im folgenden Beispiel mit einer orders-Tabelle veranschaulicht:
| order_id | Menge | customer_id |
|---|---|---|
| 1 | $25.00 | 1 |
| 2 | $50.00 | 1 |
| 3 | $75.00 | 2 |
| 4 | $35.00 | 3 |
Angenommen, Sie haben für dieses Beispiel auch die folgende customers-Tabelle:
| customer_id | first_name | last_name | Besuche |
|---|---|---|---|
| 1 | Amelia | Ohrhart | 2 |
| 2 | Logo: Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
| 4 | Karl | Yeager | 3 |
Nachdem diese Tabellen verknüpft wurden, kann die verknüpfte Tabelle so dargestellt werden:
| order_id | Menge | customer_id | customer_id | first_name | last_name | Besuche |
|---|---|---|---|---|---|---|
| 1 | $25.00 | 1 | 1 | Amelia | Ohrhart | 2 |
| 2 | $50.00 | 1 | 1 | Amelia | Ohrhart | 2 |
| 3 | $75.00 | 2 | 2 | Logo: Bessie | Coleman | 2 |
| 4 | $35.00 | 3 | 3 | Wilbur | Wright | 4 |
| null | null | null | 4 | Karl | Yeager | 3 |
Genau wie bei einem Inner Join ist die Beziehung zwischen den Primärschlüsseln der Tabellen many_to_one. Der hinzugefügte Null-Datensatz erzwingt jedoch auch die Notwendigkeit symmetrischer Summen in der linken Tabelle. Daher müssen Sie den Parameter relationship in many_to_many ändern, da durch diesen Join die Anzahl der Zählungen in der linken Tabelle unterbrochen wird.
Wäre dieses Beispiel ein Left Outer Join gewesen, wäre die Nullzeile nicht hinzugefügt und der zusätzliche Kundendatensatz entfernt worden. In diesem Fall wäre die Beziehung immer noch many_to_one. Dies ist die Looker-Standardeinstellung, da angenommen wird, dass die Basistabelle die Analyse definiert. In diesem Fall analysieren Sie Bestellungen und nicht die Kundschaft. Wenn sich die Kundentabelle auf der linken Seite befände, sähe die Situation anders aus.
Joins mit mehreren Ebenen
In einigen Explores ist die Basistabelle mit einer oder mehreren Ansichten verknüpft, die wiederum mit einer oder mehreren zusätzlichen Ansichten verbunden werden müssen. In diesem Beispiel würde dies bedeuten, dass eine Tabelle mit der Kundentabelle verbunden wird. In diesen Situationen ist es am besten, bei der Auswertung des relationship-Parameters nur auf den einzelnen Join zu achten, der geschrieben wird. Looker versteht, wann sich ein nachgelagerter Fanout auf eine Abfrage auswirkt, auch wenn sich die betroffene Ansicht nicht in dem Join befindet, der den Fanout tatsächlich erstellt hat.
Wie hilft mir Looker?
Looker bietet Mechanismen, mit denen Sie sicherstellen können, dass der Beziehungswert korrekt ist. Erstens wird die Eindeutigkeit des Primärschlüssels geprüft. Immer wenn ein Fanout vorhanden ist und symmetrische Summen zur Berechnung einer Messung erforderlich sind, prüft Looker den verwendeten Primärschlüssel auf Eindeutigkeit. Wenn er nicht eindeutig ist, wird bei der Ausführung der Abfrage ein Fehler angezeigt (es gibt jedoch keinen LookML Validator-Fehler dafür).
Wenn Looker keine Möglichkeit zur Verarbeitung eines Fanouts gibt (normalerweise, weil kein Primärschlüssel angegeben ist), werden aus dieser Ansicht im Explore keine Messwerte angezeigt. Um dies zu korrigieren, legen Sie einfach ein Feld als Primärschlüssel fest, damit Ihre Messungen in das Explore gelangen.
Wichtige Punkte
Dialektunterstützung für symmetrische Summen
Looker kann mit einigen Dialekten verbunden werden, die keine symmetrischen Summen unterstützen. Eine Liste der Dialekte und ihrer Unterstützung für symmetrische Summen finden Sie auf der Dokumentationsseite zu symmetric_aggregates.
Sonderfall
Im Abschnitt Inner Join weiter oben auf dieser Seite wurde erläutert, dass Sie zum Ermitteln des richtigen Beziehungswerts die Felder in Ihrer sql_on-Klausel aus der linken Tabelle betrachten sollten: „Wenn die Felder den Primärschlüssel der linken Tabelle bilden, können Sie die linke Seite des relationship-Parameters in one ändern. Andernfalls muss sie in der Regel als many bestehen bleiben. Dies gilt, es sei denn, Ihre Tabelle enthält mehrere Spalten, die keine wiederholten Datensätze enthalten. In diesem Fall können Sie jede solche Spalte so behandeln, als wäre sie bei der Formulierung Ihrer Beziehung ein Primärschlüssel, auch wenn es sich nicht um die Spalte mit der Bezeichnung primary_key: yes handelt.
Es kann hilfreich sein, sicherzustellen, dass eine Softwareregel vorhanden ist, die sicherstellt, dass die Anweisung im vorherigen Absatz für die von Ihnen angegebene Spalte immer wahr bleibt. Wenn ja, behandeln Sie sie als solches und notieren Sie sich die spezielle Eigenschaft in der Ansichtsdatei, damit andere sie in Zukunft referenzieren können. Geben Sie dabei den SQL-Runner-Link an, um dies zu belegen. Beachten Sie jedoch, dass Looker die Wahrheit der impliziten Eindeutigkeit bestätigt, wenn ein Feld als Primärschlüssel festgelegt ist, nicht aber für andere Felder. Es ruft einfach nicht den Algorithmus für symmetrische Summen auf.