このページでは、
derived_tableのサブパラメータであるexplore_sourceパラメータについて説明します。
explore_sourceは、testパラメータのドキュメント ページで説明されているように、testのサブパラメータにすることもできます。
用途
derived_table: customer_order_facts {
explore_source: orders {
column: customer_id {
field: orders.customer_id
}
column: order_amount {
field: orders.sale_price
}
column: item_qty {
field: orders.number_items
}
derived_column: average_item_price {
sql: order_amount / item_qty ;;
}
timezone: "America/Los_Angeles"
}
}
|
階層
explore_source |
デフォルト値
なし
許可
ネイティブ派生テーブルの派生元となる Explore の識別子と、ネイティブ派生テーブルを定義するサブパラメータ。
|
定義
派生テーブルを作成する方法は 2 つあります。派生テーブルは、データベース内の通常のテーブルと同じように使用できます。LookML パラメータを使用して定義されるネイティブ派生テーブルと、SQL クエリ ステートメントを使用して定義される SQL ベースの派生テーブルです。
explore_source パラメータは、ネイティブ派生テーブルに使用されます。このパラメータでは、ネイティブ派生テーブルに含める列、ネイティブ派生テーブルに適用するフィルタ、ネイティブ派生テーブルの行を制限または並べ替えるかどうか、ネイティブ派生テーブルの時間ベースのフィールドを別のタイムゾーンに変換するかどうかを定義します。
ネイティブ派生テーブルの定義
ネイティブ派生テーブルでは、さまざまなパラメータを使用できます。その多くは省略可能です。ネイティブ派生テーブルを定義する構文は次のとおりです。
explore_source: identifier {
bind_all_filters: yes
column: identifier {
field: field_name
}
derived_column: identifier {
sql: SQL expression ;;
}
expression_custom_filter: [custom filter expression]
filters: [field_name_1: "string", field_name_2: "string", ...]
limit: number
sorts: [field_name_1: asc | desc, field_name_2: asc | desc, ...]
timezone: "string"
}
次の表に、ネイティブ派生テーブルの定義に使用できる各パラメータに関する情報を示します。
| パラメータ名 | 説明 | 例 |
|---|---|---|
bind_filters | Explore クエリのフィルタをネイティブ派生テーブルのサブクエリに渡します。このパラメータを設定するには、from_field サブパラメータを使用して、ネイティブ派生テーブル ビューで定義されたフィールド、またはネイティブ派生テーブルが結合された Explore でアクセス可能なフィールドを指定します。実行時に、Explore の from_field のフィルタは、ネイティブ派生テーブルのサブクエリの to_field に渡されます。例については、bind_filters の使用をご覧ください。bind_filters を使用する場合は、次の点にご注意ください。
explore_source パラメータには bind_all_filters サブパラメータまたは bind_filters サブパラメータのいずれかを指定できますが、両方を指定することはできません。 |
bind_filters: {
to_field: users.created_date
from_field: user_dt.filter_date
} |
bind_all_filters |
Explore クエリのすべてのフィルタをネイティブ派生テーブルのサブクエリに渡します。このパラメータを設定するには、ネイティブ派生テーブルの explore_source で bind_all_filters: yes を指定します。例については、bind_filters の使用をご覧ください。bind_all_filters: yes を使用する場合は、次の点にご注意ください。
|
bind_all_filters: yes |
column |
explore_source に含める列を指定します。field サブパラメータがある。 |
column: cust_id {
field: orders.customer_id
} |
derived_column |
explore_source 内の列を、内部列のネームスペース内の式とともに指定します。このステップでは SQL グルーピングが存在しないため、集計 SQL 式はここでは機能しません。このパラメータでは、SQL ウィンドウ関数が非常に役立ちます。sql サブパラメータがある。 |
derived_column: average_order {
sql: order_amount / item_qty ;;
} |
dev_filters |
21.12 で追加
Looker が派生テーブルの開発バージョンにのみ適用するフィルタを指定します。これは、LookML デベロッパーが開発モードで派生テーブルをテストする際に役立ちます。dev_filters パラメータを使用すると、Looker はフィルタリングされたバージョンのテーブルをより小さく作成できます。これにより、LookML デベロッパーは、変更を行うたびにテーブル全体のビルドが完了するのを待たずに、テーブルを繰り返してテストできます。Looker は dev_filters を派生テーブルの開発バージョンにのみ適用します。ユーザーがクエリするテーブルの本番環境バージョンには適用されません。開発モードで派生テーブルを操作する方法については、Looker の派生テーブルのドキュメント ページをご覧ください。例については、このページの開発モードのフィルタを作成するをご覧ください。 |
dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"] |
expression_custom_filter |
必要に応じて、explore_source クエリにカスタム フィルタ式を指定します。 |
expression_custom_filter: ${orders.status} = "pending" ;; |
filters |
必要に応じて、explore_source クエリにフィルタを追加します。角かっこで囲みます。フィルタするフィールド名を view_name.field_name 形式で指定し、その後に : と、フィールドをフィルタする値(複数可)を指定します。フィルタは、ネイティブ派生テーブルによって生成された SQL の WHERE 句に追加されます。 |
filters: [products.department: "sweaters"] |
limit |
必要に応じて、クエリの行制限を指定します。 | limit: 10 |
sorts |
必要に応じて、この explore_source のソートを指定します。角かっこで囲みます。並べ替えるフィールド名(view_name.field_name 形式)を含め、その後に : と asc または desc を指定して、フィールドを昇順または降順で並べ替えるかどうかを示します。複数のフィールドで並べ替えるには、複数のフィールド名とキーワードのペアをカンマで区切って追加します。 |
sorts: [products.brand: asc, products.name: asc] |
timezone |
explore_source クエリのタイムゾーンを設定します。非永続的な派生テーブルの場合、タイムゾーンを "query_timezone" に設定することで、自動的に現在実行中のクエリのタイムゾーンを使用します。タイムゾーンが指定されていない場合、explore_source クエリはタイムゾーン変換を行わず、代わりにデータベースのタイムゾーンを使用します。サポートされているタイムゾーンの一覧については、timezone 値のページをご覧ください。 IDE で timezone パラメータを入力すると、IDE がタイムゾーン値を自動提案します。IDE のクイックヘルプ パネルにも、サポートされているタイムゾーン値のリストが表示されます。 |
timezone: "America/Los_Angeles" |
例
次の定義は、ネイティブ派生テーブルの基本的な例を示しています。
user_order_facts ネイティブ派生テーブルを作成します。
view: user_order_facts {
derived_table: {
explore_source: order_items {
column: user_id {
field: order_items.user_id
}
column: lifetime_number_of_orders {
field: order_items.order_count
}
column: lifetime_customer_value {
field: order_items.total_revenue
}
}
}
# Define the view's fields as desired
dimension: user_id {
hidden: yes
}
dimension: lifetime_number_of_orders {
type: number
}
dimension: lifetime_customer_value {
type: number
}
}
フィルタを追加して user_90_day_facts ネイティブ派生テーブルを作成できます。
view: user_90_day_facts {
derived_table: {
explore_source: order_items {
column: user_id {
field: order_items.user_id
}
column: number_of_orders_90_day {
field: order_items.order_count
}
column: customer_value_90_day {
field: order_items.total_revenue
}
filters: [order_items.created_date: "90 days"]
}
}
# Add define view's fields as desired
dimension: user_id {
hidden: yes
}
dimension: number_of_orders_90_day {
type: number
}
dimension: customer_value_90_day {
type: number
}
}
開発モードのフィルタを作成する
作成中のネイティブ派生テーブルを生成するのに長時間を要する場合もあり、Development Mode で多数の変更内容をテストしている場合は、時間がかかることがあります。このような場合は、dev_filters を使用して、ネイティブ派生テーブルのより小さい開発バージョンを作成できます。
view: e_faa_pdt {
derived_table: {
...
datagroup_trigger: e_faa_shared_datagroup
explore_source: flights {
dev_filters: [flights.event_date: "90 days"]
filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
column: id {}
column: airport_name {}
column: event_date {}
}
}
...
}
この例では、過去 90 日間のデータをフィルタリングして表示する dev_filters パラメータと、過去 2 年間かつ Yucca Valley Airport のデータをフィルタリングして表示する filters パラメータが含まれています。dev_filters パラメータは filters パラメータと連動して動作し、すべてのフィルタがテーブルの開発バージョンに適用されるようになります。dev_filters と filters の両方が同じ列のフィルタを指定した場合、テーブルの開発バージョンには dev_filters が優先されます。この例では、開発バージョンのテーブルは過去90日間のYucca Valley Airportのデータをフィルタリングして表示します。
ネイティブ派生テーブルに
逆の状況も当てはまります。dev_filtersパラメータがある場合、開発バージョンには省略形のデータセットが存在するため、開発テーブルを本番環境で使用することはできません。このような場合は、テーブルの開発が完了してから変更をデプロイする前に、dev_filtersパラメータをコメントアウトして、Development Mode でテーブルに対してクエリを実行できます。こうすることで、Lookerは変更をデプロイした後もプロダクションで使用可能なフルバージョンのテーブルを構築します。本番環境での開発テーブルの使用についての詳細は、Looker の派生テーブルのドキュメント ページをご覧ください。dev_filtersパラメータを含むネイティブ派生テーブルがあり、Development Mode でクエリを実行すると、Looker は本番環境テーブルを使用して Development Mode のクエリに応答できます。このステートメントは、テーブルの定義を変更してから、Development Mode でテーブルをクエリする場合を除き、真です。この場合、Looker はクエリに応答するために開発テーブルをビルドします。
ネイティブ派生テーブルへのフィルタの受け渡し
Explore にネイティブ派生テーブルを含めると、Explore からランタイム フィルタを取得して、ネイティブ派生テーブルのクエリに適用できます。これを行うには、ネイティブ派生テーブルの explore_source に bind_all_filters パラメータまたは bind_filters パラメータを追加します。
Explore からネイティブ派生テーブルのサブクエリにランタイム フィルタを渡す場合、ランタイム フィルタは、ネイティブ派生テーブルと同じ Explore に結合されたビュー内にある必要があります。また、Explore のランタイム フィルタを組み込むために、ネイティブ派生テーブルはランタイムで再生成する必要があるため、ネイティブ派生テーブルを永続派生テーブル(PDT)にすることはできません。
bind_all_filters の使用
Explore からネイティブ派生テーブルのサブクエリにフィルタを渡す最も簡単な方法は、ネイティブ派生テーブルの explore_source パラメータで bind_all_filters: yes を指定する方法です。これにより、Explore のすべてのランタイム フィルタが、ネイティブ派生テーブルのサブクエリに渡されます。
bind_all_filters: yes を含むネイティブ派生テーブルは、ネイティブ派生テーブルの explore_source パラメータで指定された同じ Explore に結合する必要があります。別の Explore でネイティブ派生テーブルを使用する場合は、bind_filters の使用セクションで説明したように、代わりに bind_filters パラメータを使用します。
bind_all_filters: yes を含むネイティブ派生テーブルの LookML は次のとおりです。
view: top_10_simple_item_names {
view_label: "Top 10s"
derived_table: {
explore_source: order_items {
column: total_sale_price {
field: order_items.total_sale_price
}
column: item_name {
field: products.item_name
}
derived_column: rank {
sql: RANK() OVER (ORDER BY total_sale_price DESC) ;;
}
bind_all_filters: yes
sorts: [order_items.total_sale_price: desc]
timezone: "query_timezone"
limit: 10
}
}
dimension: item_name {
group_label: "Simple Example"
}
dimension: rank {
type: number
group_label: "Simple Example"
}
dimension: item_name_ranked {
group_label: "Simple Example"
order_by_field: rank
type: string
sql: ${rank} || ') ' || ${item_name} ;;
}
}
ネイティブ派生テーブルのビューでは、explore_source は order_items です。次の LookML は、ネイティブ派生テーブルが Explore に結合されている order_items Explore のものです。
explore: order_items {
...
join: top_10_simple_item_names {
type: inner
relationship: many_to_one
sql_on: ${products.item_name} = ${top_10_simple_item_names.item_name} ;;
}
}
この例の動作については、[分析ブロック] - 上位 X 件でピボット - bind_all_filters: yes のご紹介のコミュニティ投稿をご覧ください。
bind_filters の使用
explore_source の bind_filters サブパラメータは、Explore クエリの特定のフィルタをネイティブ派生テーブルのサブクエリに渡します。
to_fieldは、フィルタが適用されるネイティブ派生テーブル内のフィールドです。to_fieldは、基盤となるexplore_sourceのフィールドでなければなりません。from_fieldは、ユーザーが実行時にフィルタを指定した場合に、フィルタの取得元となる Explore 内のフィールドを指定します。
実行時に、Explore の from_field のフィルタは、ネイティブ派生テーブルのサブクエリの to_field に渡されます。
次の LookML は、bind_filters を含むネイティブ派生テーブルを示しています。この設定により、Looker は、Explore の filtered_lookml_dt.filter_date フィールドに適用されたフィルタを取得して、ネイティブ派生テーブルの users.created_date フィールドに適用します。
derived_table: {
explore_source: order_items {
bind_filters: {
to_field: users.created_date
from_field: filtered_lookml_dt.filter_date
. . .
}
}
}
注意点
explore_source パラメータは 1 つのみ使用する
各ネイティブ派生テーブルは 1 つの explore_source パラメータのみを受け入れます。後続の explore_source パラメータでは LookML 検証エラーは発生しませんが、前の explore_source パラメータがオーバーライドされます。
異なるビューのフィールドから列を作成するには、まず同じ Explore で異なるビューを結合します。次に、その探索を explore_source に使用します。
include ステートメントを使用して参照フィールドを有効にする
ネイティブ派生テーブルを作成するときは、Explore の定義を含むファイルを含める必要があります。別の Explore ファイルで対象の Explore を定義するのが最善の方法です。詳しくは、Explore ファイルの作成のドキュメントをご覧ください。
別の Explore ファイルを作成する場合:
- ネイティブ派生テーブルのビューファイルには次のように Explore のファイルを含める必要があります。例:
-
include: "/explores/order_items.explore.lkml"
-
- Explore のファイルには次のように必要なビューファイルを含める必要があります。例:
-
include: "/views/order_items.view.lkml" -
include: "/views/users.view.lkml"
-
- モデルには次のように Explore のファイルを含める必要があります。例:
-
include: "/explores/order_items.explore.lkml"
-