SQL_on

Nutzung

Explore: view_name_1 {
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}

Hierarchie Modelldatei explore join sql_on

Standardwert Keine Akzeptiert Eine SQL-ON-Klausel Sonderregeln sql_on, sql_foreign_key und foreign_key dürfen nicht gleichzeitig innerhalb derselben join verwendet werden

Definition

sql_on stellt anhand einer von Ihnen bereitgestellten SQL-ON-Klausel eine Join-Beziehung zwischen einer Ansicht und der Funktion „Erkunden“ her.

Bei LookML spielt die Reihenfolge der Bedingungen in sql_on keine Rolle. sql_on: ${order.user_id} = ${user.id} ;; und sql_on: ${user.id} = ${order.user_id} ;; sind also gleichwertig. Sie können die Bedingungen in eine beliebige Reihenfolge bringen, es sei denn, die Reihenfolge ist für den SQL-Dialekt Ihrer Datenbank relevant.

Eine Ansicht kann direkt mit einem explorativen Analysetool verknüpft werden, wenn sql_on verwendet wird, oder über eine zweite Ansicht, die bereits mit diesem explorativen Analysetool verknüpft ist.

Hier ein Beispiel für den ersten Fall, bei dem eine Ansicht direkt mit dem Tab „Entdecken“ verknüpft wurde:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

SQL generiert Looker aus diesem LookML:

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

Im zweiten Fall wird eine Ansicht über eine Zwischenansicht, die bereits mit dieser Funktion verknüpft ist, mit einer anderen Datenansicht verknüpft. Hier ein Beispiel:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Hier kann customer nicht direkt mit order_items verknüpft werden. Sie muss stattdessen über order verknüpft werden. SQL generiert Looker aus diesem LookML:

SELECT    ...
FROM      order_items
LEFT JOIN order
ON        order_items.order_id = order.id
LEFT JOIN customer
ON        order.customer_id = customer.id

Damit dies richtig funktioniert, müssen Sie in unseren Feldreferenzen nur die richtigen Ansichtsnamen verwenden. Da customer mit einem Feld in order verknüpft werden muss, verweisen wir auf ${order.customer_id}.

In einigen älteren Modellen werden möglicherweise Felder angezeigt, auf die die Syntax view_name.native_column_name verweist. Dies funktioniert zwar weiterhin, die Verwendung der ${view_name.looker_dimension_name}-Syntax hat jedoch einen wichtigen Vorteil: Du kannst den Parameter required_joins vermeiden. Dieses Konzept wird im Abschnitt required_joins verwenden, wenn die ${view_name.looker_dimension_name}-Syntax nicht verwendet werden kann auf dieser Seite ausführlicher erläutert.

Bedingte Joins

Es ist auch möglich, die Verwendung der Nutzereingabe in sql_on zuzulassen. Auch wenn dies verschiedene Gründe haben kann, ist die Optimierung der Abfragegeschwindigkeit in MPP-Datenbanken wie Redshift ein wichtiger Anwendungsfall. Weitere Informationen hierzu finden Sie in diesem Community-Thema.

Wenn Sie Ihrer Join-Bedingung Nutzereingaben hinzufügen möchten, müssen Sie zuerst einen Filter für deren Eingabe erstellen. Diese Filtertypen werden auf der Seite Vorlagenvorlagen genauer beschrieben. Ihre grundlegende Form lautet:

view: view_name {
  filter: filter_name {
    type: number | datetime | date | string
  }
}

Nachdem Sie einen Filter zum Erfassen der Nutzereingabe hinzugefügt haben, verwenden Sie ihn im sql_on-Parameter:

{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}

Beispiel:

explore: order {
  join: customer {
    sql_on:
      ${order.customer_id} = ${customer.id} AND
      {% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
  }
}

Dies würde so ausgelegt: „customer.created_at“ ist gleich dem Wert von customer.creation_date_filter.

_in_query, _is_selected und _is_filtered Liquid-Variablen verwenden

Die Flüssigkeitsvariablen _in_query, _is_selected und _is_filtered können in Kombination mit dem Parameter sql_on hilfreich sein. Sie können Join-Beziehungen basierend auf den Feldern ändern, die ein Nutzer für seine Abfrage ausgewählt hat. Beispiel:

explore: dates {
  join: dynamic_order_counts {
    sql_on:
      ${dynamic_order_counts.period} =
      {% dynamic if dates.reporting_date._in_query %}
        ${dates.date_string}
      {% elsif dates.reporting_week._in_query %}
        ${dates.week_string}
      {% dynamic else %}
        ${dates.month_string}
      {% dynamic endif %} ;;
  }
}

Beispiele

Verknüpfen Sie die Ansicht „customer“ mit dem Bericht „Erkunden“ mit dem Namen „order“, indem Sie die Dimension „customer_id“ aus „order“ mit der Dimension „id“ aus customer abgleichen:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Verbinden Sie die Ansicht namens customer mit der Ansicht order_items über die Ansicht order. Gleichen Sie die Dimension customer_id aus order mit der Dimension id aus customer ab. Gleichen Sie die Dimension order_id aus order_items mit der Dimension id aus order ab. Diese wird folgendermaßen angegeben:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Verbinden Sie die Ansichten order und inventory_items mit dem Tab „Erkunden“ mit dem Namen order_items. Gleichen Sie die Dimension inventory_id aus order_items mit der Dimension id aus inventory_item ab. Gleichen Sie die Dimension order_id aus order_items mit der Dimension id aus order ab. Diese wird folgendermaßen angegeben:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: inventory_item {
    sql_on: ${order_items.inventory_id} = ${inventory_item.id} ;;
  }
}

Wichtige Informationen

required_joins verwenden, wenn die ${view_name.looker_dimension_name}-Syntax nicht verwendet werden kann

Wenn Sie in sql_on Felder mit der Syntax ${view_name.looker_dimension_name} verweisen, müssen Sie sich nicht um die Verwendung von required_joins kümmern.

Einige ältere Modelle verwenden jedoch weiterhin die Syntax view_name.native_column_name. Es gibt auch Fälle, in denen Sie die Syntax ${view_name.looker_dimension_name} nicht verwenden können, z. B. wenn Sie benutzerdefinierten SQL-Code anwenden möchten.

In diesen Fällen müssen Sie möglicherweise required_joins verwenden. Sie werden auf der Dokumentationsseite zum Parameter required_joins ausführlicher beschrieben.