表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

このページは Cloud Translation API によって翻訳されました。

一般的な LookML パターン

このページでは、LookML の次の一般的なパターンについて説明します。

フィールド（およびUIの名前）へのラベル付け
ディメンションによるカウントのフィルタリング
パーセント
セットを使用した詳細のドリルダウン
結果セットのフィルタリング

フィールド（およびUIの名前）へのラベル付け

Looker は、通常のフォントのビュー名と太字のフィールドの短縮名を組み合わせることで、LookML のフィールド名を UI に表示される文字列に変換します。たとえば、[Orders] ビューの [Amount] というフィールドは、UI では Orders [Amount] と表示されます。このページでは、わかりやすいように両方のフィールド名を太字で、ビュー名を大文字で記載しています（ORDERS Amount）。

フィールドの名前をテーブル内の列名と異なるものにする場合は、フィールド名を変更し、sql パラメータを使用して、フィールドをテーブル内の適切な列にリンクします。次の例では、airports テーブルに cntrl_twr 列があります。Lookerは以下の宣言を生成します。

view: airports {
  dimension: cntrl_twr {        # full name: airports.cntrl_twr
    type: yesno                 # default name: AIRPORT Cntrl Twr (Yes/No)
    sql: ${TABLE}.cntrl_twr ;;  # the sql expression for this field
  }
}

cntrl_twr ディメンションの名前を変更して、人が読めるようにすることができます。

view: airports {
  dimension: has_control_tower {  # full name: airports.has_control_tower
    type: yesno                   # aliased name: AIRPORTS Has Control Tower (Yes/No)
    sql: ${TABLE}.cntrl_twr ;;    # the sql expression for this field
  }
}

ディメンションによるカウントのフィルタリング

ディメンションごとにグループ化してエンティティをカウントできます。ユーザーの国でグループ化すると、注文数で国別に注文の発生元を確認できます。しかし、多くの場合、なんらかのディメンション値でフィルタリングしたカウントを作成すると便利です。たとえば、新しいメジャーを作成して「ORDERS France Count」という名前を付けることができます。

view: users {
  dimension: country {}
}
view: orders {
  dimension: id {
    primary_key: yes
    sql: ${TABLE}.id ;;
  }
  measure: count {
    type: count
    drill_fields: [detail]
  }
  measure: france_count {
    type: count   # COUNT(CASE WHEN users.country = 'France' THEN 1 ELSE NULL END)
    filters: [users.country: "France"]
  }
}

フィルタでは任意の式を使用できます。 EU諸国のユーザーを数えるフィールドが必要な場合には、以下のようなものを使用できます。

measure: eu_count {
  type: count   # COUNT(CASE WHEN users.countrycode IN 'UK','FR','ES' THEN 1 ELSE NULL END)
  drill_fields: [detail]
  filters: [users.countrycode: "UK,FR,ES"]
}

数式でフィルタする場合は、必ず二重引用符で囲みます。

measure: total_orders_above_100_dollars {
  type: sum   # SUM(CASE WHEN order.value > 100 THEN order.value ELSE NULL END)
  sql: ${order.value} ;;
  drill_fields: [detail]
  filters: [order.value: ">100"]
}

パーセント

重要業績評価指標の多くは、"返品率"、"販売につながったメールの割合"、またはその他の"YであるXの割合"というようなパーセント形式で表現されます。これをLookMLで表現するには、2つの条件のカウントを作成し、この2つのフィールド間のパーセントを計算するための3番目のフィールドを作成します。

dimension: returned {
  type: yesno
}
measure: count {   # total count of items
  type: count_distinct
  sql: ${TABLE}.id ;;
  drill_fields: [detail]
}
measure: returned_count {   # count of returned items
  type: count_distinct
  sql: ${TABLE}.id ;;
  drill_fields: [detail]
  filters: [returned: "Yes"]
}
measure: percent_returned {
  type: number
  sql: 100.0 * ${returned_count} / NULLIF(${count}, 0) ;;
  value_format: "0.00"
}

パーセントを計算する場合には、次の形式を使用してください。Postgresではカウントは整数であり、整数間の割り算も整数となります。 100.0との掛け算により、最初のカウントが浮動小数点数に変換されるため、残りの式も浮動データに変換されます。ゼロ除算エラーを回避するために、NULLIF(value, 0) は 0 値を null に変換します。これにより、結果が null になり、エラーを回避できます。

100.0 * ${returned_count} / NULLIF(${count}, 0)

セットを使用した詳細のドリルダウン

Lookerの最もパワフルな機能の1つに、データをドリルダウンして、カウントまたはその他のメジャーを構成する基となるエンティティを参照できる機能があります。

UI でメジャーをクリックすると、Looker は新しいクエリを作成して、メジャーを構成するデータセットをローカライズします。テーブル内の行のディメンションごとの値がすべて

詳細を表示するために、Looker にはメジャーの値がクリックされたときに表示する指定のドリルフィールドが必要となります。モデルを生成すると、通常、ジェネレータがユーザー用に最初のドリルフィールドを複数作成します。さらに、ユーザー自身もドリルフィールドを追加できます。たとえば、ユーザーの州ごとに先週の注文数を測定しているとします。Looker のクエリは以下のように表示されます。

USERS State	ORDERS Count
カリフォルニア	24
Texas	5
Colorado	4
フロリダ	4
Illinois	4

たとえば、カリフォルニア州の行で 24 をクリックすると、カリフォルニア州からの 24 件の注文が表示されることになります。Looker は USERS State: California というフィルタを追加しますが、注文で表示するフィールドがわかりません。まず、セットを使用してモデルでそれらのフィールドを宣言する必要があります。

LookML では、セットとはフィールド（ディメンション、メジャー、フィルタ）の名前のリストを指します。セットを使用すると、Looker に次の情報を提供できます。

カウントまたは他のメジャーにドリルダウンするときに表示するフィールド
ビューを結合するときにインポートするフィールド
Explore でインデックスに登録するフィールド

同じセットをモデル内のさまざまな箇所で使用できるため、Looker にはセットを作成するいくつかの方法があります。

リテラルセット

リテラルセットは、特にセットが 1 回だけ使用される場合に、LookML でセットを定義する簡単な方法です。リテラルセットは、セットを配列として宣言することにより作成できます。リテラルセットの宣言には　[]　を使用します。

次に例を示します。

view: customers {
  dimension: id {
    primary_key: yes
  }
  measure: count {
    type: count
  }
  dimension: city {}
  dimension: state {}
  dimension: name {}
}

この例では、表示するフィールドは id、name、city です。

メジャーでは、リテラル配列を次のように宣言できます。

measure: count {
  type: count
  drill_fields: [id, name, city]
}

名前付きセット

customers ビューに count と in_california_count の 2 つのカウントが定義されているとします。ユーザーが Explore で [Count] フィールドまたは [In California Count] フィールドにドリルダウンしたときに、id、name、およびcity　を表示します。

最初は、これらのフィールドをリテラルに宣言すれば十分と思われるかもしれません。

view: customers {
  measure: count {
    type: count
    drill_fields: [id, name, city]
  }
  measure: in_california_count {
    type: count
    filters: [state: "California"]
    drill_fields: [id, name, city]
  }
}

ただし、新しいフィールド（customers.state など）を追加する場合は、両方のリストを編集する必要があります。この場合、set パラメータを使用して、複数の名前付きセットがあって 1 か所で維持し、複数の場所で使用する場合は除きます。

次のコードは、セット customers.detail を作成し、両方のカウントが同じフィールドのセットを指すようにします。

view: customers {
  set: detail {
    fields: [id, name, city]      # creates named set customers.detail
  }

  measure: count {
    type: count
    drill_fields: [detail*]       # show fields in the set "customers.detail"
  }
  measure: in_california_count {
    type: count
    filters: [state: "California"]
    drill_fields: [detail*]      # show fields in the set "customers.detail"
  }
}

LookML セットは、次のような点で強力です。

セットの再宣言は追加型です。1 つのセットを複数の箇所で宣言すると、Looker はすべての場所でそのセットに宣言されたフィールドをすべて含めます。
他のセット名とそれに続くアスタリスクを入力することで、セットを他のセットに埋め込むことができます（例: setname*）。
フィールド名の前にハイフンを入力することで、セットから要素を削除できます（例: -fieldname）。

ドリルビジュアリゼーションのカスタマイズ

Looker 管理者が ビジュアルドリル Labs 機能を有効にしている場合、Look と Explore ドリルのビジュアリゼーションが常にデータテーブルをデフォルトにするとは限りません。この場合、linkパラメータのドキュメントページとより強力なデータドリルダウンベストプラクティスのページに示されているように、link パラメータで Liquid 変数を使用して表示されるビジュアリゼーションをカスタマイズできます。

ダッシュボードでは、ビジュアルドリル Labs 機能を有効にしなくても、link パラメータを使用してビジュアルドリルをサポートします。

結果セットのフィルタリング

LookMLに用意されている一連のフィルタ操作をフィールドやExploreに適用して、結果セットをフィルタリングしてからユーザーに返すことができます。

Explore の `always_filter`

always_filter を使用すると、Explore 内で実行されるすべてのクエリに一連のフィルタを常に適用できます。フィルタはLookerのUIに表示されます。ユーザーはデフォルトのフィルタ値を変更できますが、フィルタを削除することはできません。一般的に、これらのフィルタは、通常は除外するデータの削除に使用します。たとえば、[注文] の Explore で、完了した注文または保留中の注文のみを確認する必要があるとします。次の LookML コードを追加できます。

explore: orders {
  view_name: order
    filters: [status: "complete,pending"]
  }
}

その他のステータス値を持つ注文を確認するには、UI で [注文ステータス] を [%] に設定します。

Explore の `sql_always_where`

ユーザーが変更できないクエリ制限を適用する場合は、sql_always_where を使用できます。ユーザーが実行するクエリ以外にも、ダッシュボード、スケジュール化されたLook、そのExploreに依存する組み込まれた情報などに適用されます。 sql_always_where 条件は、ユーザーが作成するクエリの基盤となる SQL を確認しない限り、ユーザーには表示されません。

以下の例では、ユーザーが2012年1月1日より前の注文を見ることができないように制限しています。

# Using Looker references
explore: order {
  sql_always_where: ${created_date} >= '2012-01-01' ;;
}

# Using raw SQL
explore: order {
  sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}

Explore の `conditionally_filter`

非常に大規模なテーブルでクエリを実行する場合には、クエリに制限がないと、データベースの負荷が過大になるため、なんらかの配慮が必要です。 LookML では、conditionally_filter という形式でこの問題に対処できます。

ユーザーが unless セクションに記載のフィールドの 1 つにフィルタを追加済みの場合を除いて、conditionally_filter パラメーターを使用してフィルタをクエリに適用します。

次の例では、ユーザーが created_date、shipped_time、shipped_date、orders.id、または customer.name のうち 1 つ以上のフィールドに対してフィルタを適用している場合、ユーザーのクエリは変更されません。ユーザーがこれらのいずれのフィールドにもフィルタを適用しなかった場合、Looker は orders.created_time に 1 日間のフィルタを自動的に追加します。

  filters: [orders.created_time: "1 day"]
  unless: [created_date, shipped_time, shipped_date, orders.id, customer.name]
}