一般的な 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
  }
}

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

ディメンションとカウントのエンティティでグループ化できます。[ユーザーの国] でグループ化すると、[注文数] によって、どの国から注文されたかがわかります。しかし、多くの場合、一定のディメンション値でフィルタリングするカウントを作成すると便利な場合があります。たとえば、新しいメジャーを作成して、「フランスからの注文数」という名前を付けることができます。

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) はゼロ値を 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 を追加しますが、Looker は注文に表示するフィールドを認識しません。まず、セットを使用して、モデルでそれらのフィールドを宣言する必要があります。

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

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

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

リテラルセット

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

次に例を示します。

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 セットは次の点で強力です。

• セットの再宣言は追加型です。複数の場所でセットを宣言した場合、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 セクションにリストされているフィールドのいずれかにフィルタを追加していない場合は、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]
}