このページでは、
derived_table
のサブパラメータであるexplore_source
パラメータについて説明します。
explore_source
は、test
のサブパラメータにすることもできます。詳しくは、test
パラメータのドキュメントをご覧ください。
使用状況
explore_source: orders {
column: customer_id{
階層
explore_source |
デフォルト値
なし許可
ネイティブ派生テーブルの派生元となる Explore の識別子と、ネイティブ派生テーブルを定義するサブパラメータ。 |
定義
派生テーブルをデータベース内の通常のテーブルのように使用できる方法には、LookML パラメータを使用して定義されるネイティブ派生テーブルと、SQL クエリ ステートメントを使用して定義されるSQL ベースの派生テーブルの 2 種類があります。
explore_source
パラメータは、ネイティブ派生テーブルに使用されます。このパラメータでは、ネイティブ派生テーブルに含める列、ネイティブ派生テーブルの行を制限または並べ替えるかどうか、ネイティブ派生テーブルの時間ベースのフィールドを別のタイムゾーンに変換するかどうかを定義します。
ヒント: ネイティブ派生テーブルを最も簡単に作成するには、Explore を使用して必要なクエリを作成し、Explore から [Get LookML] オプションを選択します。Looker によってクエリの派生テーブル LookML が生成され、これを LookML プロジェクトのビューファイルにコピーできる。詳細については、ネイティブ派生テーブルの作成に関するドキュメント ページをご覧ください。
ネイティブ派生テーブルの定義
ネイティブ派生テーブルでさまざまなパラメータを使用できますが、その多くはオプションです。ネイティブ派生テーブルを定義する構文と、各パラメータに関する追加情報を以下に示します。
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 では、次の点に注意してください。
• ランタイム フィルタは、ネイティブ派生テーブルと同じ Explore に結合されたビューに存在する必要があります。 • ネイティブ派生テーブルを永続的な派生テーブル(PDT)にすることはできません。 • explore_source パラメータに bind_all_filters サブパラメータまたは bind_filters サブパラメータのいずれかを指定できますが、両方を含めることはできません。 |
bind_filters: { |
bind_all_filters |
Explore クエリからのすべてのフィルタをネイティブ派生テーブルのサブクエリに渡します。これを設定するには、ネイティブ派生テーブルの explore_source で bind_all_filters: yes を指定します。例については、以下のセクションをご覧ください。
bind_all_filters: yes では、次の点に注意してください。
• ランタイム フィルタは、ネイティブ派生テーブルと同じ Explore に結合されたビューに存在する必要があります。 • ネイティブ派生テーブルを PDT に作成することはできません。 • ネイティブ派生テーブルは、ネイティブ派生テーブルの explore_source パラメータで指定された Explore にのみ結合できます。これは、bind_all_filters で Explore のフィルタされたフィールドをネイティブ派生テーブルのフィールドにマッピングする必要があるためです。• explore_source パラメータに bind_all_filters サブパラメータまたは bind_filters サブパラメータのいずれかを指定できますが、両方は使用できません。 |
bind_all_filters: yes
|
column |
explore_source に含める列を指定します。field サブパラメータがあります。 |
column: cust_id { |
derived_column |
explore_source 内の列を、内部列の名前空間の式で指定します。このステップでは SQL のグループ化がないため、集計 SQL 式はここでは機能しません。このパラメータでは、SQL ウィンドウ関数が非常に便利です。sql サブパラメータがあります。 |
derived_column: average_order { |
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: |
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 パラメータを入力すると、タイムゾーン値が自動的に提案されます。また、クイックヘルプパネルには、サポートされているタイムゾーン値のリストが表示されます。 |
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
}
}
開発モード用のフィルタの作成
開発されたネイティブ派生テーブルの生成に時間がかかる場合があり、開発モードで多くの変更をテストする場合は、時間がかかることがあります。このような場合は、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 年間とユッカバレー空港へのデータをフィルタリングする filters
パラメータが含まれています。dev_filters
パラメータは filters
パラメータと連携して、すべてのフィルタがテーブルの開発バージョンに適用されるようにします。dev_filters
と filters
の両方で同じ列にフィルタが指定されている場合は、テーブルの開発バージョンが優先されます。この例では、開発バージョンのテーブルは過去90日間のYucca Valley Airportのデータをフィルタリングして表示します。
ネイティブ派生テーブルに
dev_filters
パラメータがある場合、開発バージョンには短縮形のデータセットがあるため、開発テーブルを本番環境バージョンとして使用することはできません。この場合、テーブルの開発が完了した後、変更をデプロイする前に、dev_filters
パラメータをコメントアウトしてから、開発モードでテーブルをクエリできます。これにより、変更をデプロイする際に本番環境で使用できる完全版のテーブルが作成されます。本番環境における開発テーブルの使用方法については、Looker の派生テーブルをご覧ください。
その逆の状況が真になることに注意してください。dev_filters
パラメータを持つネイティブ派生テーブルがあり、開発モードでクエリする場合、Looker では本番環境テーブルを使用して開発モードのクエリに応答できます。これは、テーブルの定義を変更してから開発モードでテーブルをクエリする場合を除いて、有効です。その時点で、Looker はクエリに応答する開発テーブルを作成します。
ネイティブ派生テーブルにフィルタを渡す
Explore にネイティブ派生テーブルを含めると、Explore からランタイム フィルタを取得し、ネイティブ派生テーブルのクエリに適用できます。これを行うには、bind_all_filters
または bind_filters
パラメータをネイティブ派生テーブルの explore_source
に追加します。
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_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
です。order_items
Explore 用の LookML を次に示します。ネイティブ派生テーブルが 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} ;;
}
}
この例の使用例は、[Analytic Block] - Pivot by Top 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 を 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"