Looker 22.16 のドキュメントを表示しています。最新のドキュメントはこちらをご覧ください。

LookMLの用語と概念

置換演算子（$）、スコープ設定と命名、SQL 言語、SQL ブロックのセクションを新しい SQL の組み込みに関するドキュメントページに移動しました。

概要

このページでは、LookML の開発で繰り返し使用される用語とコンセプトを定義します。次の図は、他の要素に含まれる要素間の関係を示しています。ここで使用されているすべての用語は、以下のセクションで定義されています。

Look とユーザー定義ダッシュボードは、ユーザーが LookML を使用せずに作成するため、この図には含まれません。ただし、これらのクエリは、前の図に示された、基礎となるLookMLの要素に依存します。

LookML プロジェクト

プロジェクトは、データベーステーブルがどのように相互に関係しているか、またLookerがそれらのテーブルをどのように解釈するかを規定するLookMLファイルのコレクションで形成されています。各 LookML プロジェクトは、バージョン管理のために独自の Git リポジトリに存在する。

以下は、LookMLプロジェクトで使用される一般的なファイルタイプです。

モデルには、使用するテーブルとテーブルの結合方法に関する情報が含まれます。モデルでは通常、モデルとモデルのExploreおよびjoinを定義します。
ビューには、各テーブル（または複数の結合されたテーブル）の情報にアクセスまたは計算する方法についての情報が含まれます。通常、ビュー、ビューのディメンションとメジャー、フィールドセットを定義します。
Exploreはモデルファイル内で定義されることが多いが、派生テーブルの場合またはモデル間で　Explore を拡張または絞り込みする場合、別の Explore ファイルが必要になることがあります。
マニフェストファイルには、別のプロジェクトからインポートされたファイルの使用手順またはプロジェクトのローカライズ設定に関する手順を含めることができます。

LookML プロジェクトに含めることができる他の種類のファイルについては、LookML プロジェクトファイルのドキュメントをご覧ください。

Looker をデータベースに接続すると、Looker プロジェクトに使用するデータベースの接続を指定できます。

Looker の [Develop] メニューからプロジェクトにアクセスできます。

Looker 21.12 以降、管理者が拡張ナビゲーション Labs 機能を有効にしている場合は、新しい拡張左側のナビゲーションパネルで [Develop] オプションを選択すると、プロジェクトにアクセスできます。

LookMLプロジェクトとファイルのソース

LookML ファイルを作成する最も一般的な方法は、データベースから LookML プロジェクトを生成することです。また、空のプロジェクトを作成して LookML ファイルを手動で作成したり、既存の Git リポジトリのクローンを作成してプロジェクトを作成したりできます。

新しいプロジェクトをデータベースから生成する場合、プロジェクトを作成するためのテンプレートとして使用できる、以下のファイルのベースラインがLookerによって作成されます。

複数のビューファイル、データベース内の各テーブルにそれぞれ1つのファイル。
1つのモデルファイル。モデルファイルでは、各ビューにそれぞれ1つのExploreが宣言されます。各 Explore の宣言には、Looker が Explore に関連すると判断できるビューを結合する join ロジックが含まれています。

ここから、不要なビューやExploreを削除したり、カスタムディメンションやメジャーを追加したりして、プロジェクトをカスタマイズすることができます。

主なLookML構造体

前の図に示すように、プロジェクトには、通常、モデルとその Explore と結合を定義するパラメータを含む 1 つ以上のモデルファイルが含まれます。さらに、プロジェクトには通常、1つ以上のビューファイルも含まれ、各ファイルにはそのビュー、ビューのフィールド（ディメンションとメジャーを含む）、フィールドセットを定義するパラメーターが入ります。またプロジェクトには、他のプロジェクトを使用するための、またはローカライゼーションのデフォルト設定を構成するためのパラメーターを含むプロジェクトマニフェストファイルが含まれる場合があります。このセクションでは、主な構造体について説明します。

モデル

モデルは、特定のビジネスユーザーに直観的なデータ探索を提供するように設計された、データベースへのポータルです。 1つのLookMLプロジェクトに、同じデータベース接続に対して複数のモデルが存在することがあります。各モデルは、異なるデータを異なるユーザーに公開することができます。例えば、販売代理店は企業の役員とは異なるデータを必要とするため、2つのモデルを開発し、各ユーザーに適したデータベースへのビューを提供することができます。

Lookerでは、クエリはそれが属するモデルによってグループ化されます。 [探索] メニューの下にユーザーがモデルを表示します。

Looker 21.12 で、管理者が拡張ナビゲーション Labs 機能を有効にしている場合、新しい拡張左側のナビゲーションパネルで Explore オプションを選択すると、Explore にアクセスして Explore のリストを表示できます。

モデルファイルでは、接続先のデータベースを指定し、その接続の Explore のコレクションを定義します。慣例として、各ファイルは 1 つのモデルのみを宣言し、新しい LookML では、モデルのファイル名は .model.lkml で終わります。モデルファイルの名前によって、Lookerで表示される名前が決まります。

次に、LookML でのモデル宣言の一般的な形式を示します。詳細については、モデルパラメータのドキュメントをご覧ください。

connection: connection_name
persist_for: timeframe
case_sensitive: yes | no
include: "filename_pattern"   # for example: *.view.lkml
# More include declarations

explore: explore_name {
  view_name: view_name
  join: view_name {
    # join parameters
  }
  # More join declarations
}
# More explore declarations

表示

ビュー宣言は、フィールド（ディメンションまたはメジャー）のリストと、基になるテーブルまたは派生テーブルへのリンクを定義します。LookML では通常、基盤となるデータベーステーブルを参照しますが、派生テーブルを表すこともできます。

ビューは他のビューと結合できます。ビュー間の関係は通常、モデルファイル内の Explore 宣言の一部として定義されます。

Lookerでは、データ表のディメンション名とメジャー名の先頭にビュー名が付きます。この命名規則により、フィールドが属するビューが明確になります。

ビューは .view.lkml ファイルに格納されます。次に、ビュー宣言の一般的な形式を示します。使用方法の詳細については、パラメータの表示に関するドキュメントページをご覧ください。

view: view_name {
  dimension: field_name {
    # dimension_parameters
  }
  # more dimension declarations
  measure: field_name {
    # measure_parameters
  }
  # more measure declarations
  set: first_set {
    fields: [field_one, field_two]
  }
}

Explore で type: count のメジャーを使用すると、ビジュアリゼーションに「Count」という単語ではなく、ビュー名で結果のラベルが付けられます。混乱を避けるため、ビジュアリゼーション設定の [Series] で [Show Full Field Name] を選択するか、複数形のビュー名を持つ view_label を使用することをおすすめします。

探索

Explore はユーザーがクエリを実行できるビューです。Explore はクエリの出発点と考えることができます。また、SQL 用語では、SQL ステートメントでは FROM と考えることができます。すべてのビューが関心のあるエンティティを表すわけではないので、すべてのビューがExploreであるとは限りません。たとえば、州名のルックアップテーブルに対応する状態ビューは、ビジネスユーザーが直接クエリする必要はないため、Explore を保証するものではありません。一方、ビジネスユーザーは「注文」ビューをクエリする方法を探していることが多いため、注文の Explore を定義することは理にかなっています。

explore 宣言は、他のビューとの結合関係を指定します。上記の例では、[Orders] ビューが [States] ビューに加わり、販売が行われた州を特定できます。詳しくは、結合をご覧ください。

Looker では、ユーザーは [Explore] メニューに Explore を表示します。

慣例として、モデルファイルでは Explore を宣言します。次の例は、e コマースデータベースの orders Explore の宣言を示しています。ビュー orders と customers は、それぞれのビューファイルの別の場所で定義されます。

# ———————————————
# file: ecommercestore.model.lookml
# ———————————————
connection: order_database
include: "filename_pattern"   # include all the views
explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

join の宣言について詳しくは、結合をご覧ください。詳しい使用方法については、結合パラメータのドキュメントをご覧ください。

ディメンションとメジャーのフィールド

ビューには、フィールド、主にディメンションとメジャーが含まれます。これらは、Lookerクエリの基本的な構成要素となります。

Lookerでは、ディメンションはグループ化可能なフィールドであり、クエリ結果をフィルタリングするために使用できます。 Mobility Print を実行できるシステムは次のとおりです。

基になるテーブルの列に直接関連する属性
ファクト、または数値
単一の行の他のフィールドの値に基づいて計算された派生値

たとえば、[商品] ビューのディメンションには、商品名、商品モデル、商品の色、商品価格、商品の作成日、商品のサポート終了日を含めることができます。

メジャーは SQL の集計関数（COUNT、SUM、AVG、MIN、MAX など）を使用するフィールドです。他のメジャー値の値に基づいて計算されたフィールドもメジャーです。メジャーを使用して、グループ化された値をフィルタリングできます。たとえば、「販売」ビューのメジャーアイテムには、販売されたアイテムの総数（個数）、合計販売価格（合計）、平均販売価格（平均値）などがあります。

フィールドの動作と期待値は、宣言された型（string、number、time など）によって異なります。メジャーの場合、型には sum や percent_of_previous などの集計関数が含まれます。詳しくは、ディメンションのタイプとメジャーのタイプをご覧ください。

Looker では、フィールドはページの左側にあるフィールド選択ツールのExploreページに一覧表示されています。

慣例により、フィールドは、所属先ビューの一部として宣言され、ビューファイルに格納されています。以下の例は、いくつかのディメンションとメジャーの宣言を示しています。完全スコープの SQL 列名を使用せずにフィールドを参照するには、置換演算子（$）を使用します。

以下に、ディメンションとメジャーの宣言の例を示します。

view: orders {
  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }
  dimension: customer_id {
    sql: ${TABLE}.customer_id ;;
  }
  dimension: amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.amount ;;
  }
  dimension_group: created {
    type: time
    timeframes: [date, week]
    sql: ${TABLE}.created_at ;;
  }
  measure: count {
    type: count           # creates sql COUNT(orders.id)
    sql: ${id} ;;
  }
  measure: total_amount {
    type: sum             # creates sql SUM(orders.amount)
    sql: ${amount} ;;
  }
}

また、複数の時間関連ディメンションを一度に作成する dimension_group と、テンプレート化されたフィルタなどの高度なユースケースを持つ filter フィールドを定義することもできます。

フィールドの宣言と適用可能な各種設定について詳しくは、フィールドパラメータに関するドキュメントページをご覧ください。

結合

explore 宣言の一部として、join 宣言ごとに explore に結合できるビューを指定します。ユーザーが複数のビューのフィールドを含むクエリを作成すると、Lookerは自動的にSQL joinのロジックを生成して、すべてのフィールドを正しくインポートします。

explore 宣言の join の例を次に示します。

# ———————————————
# file: ecommercestore.model.lookml
# ———————————————
connection: order_database
include: "filename_pattern"   # include all the views
explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

詳細については、LookML での結合の操作をご覧ください。

プロジェクトマニフェストファイル

プロジェクトには、プロジェクトレベルの設定ファイルを含めることができます。これは、現在のプロジェクトにインポートする他のプロジェクトの指定、LookML 定数の定義、モデルのローカライズ設定の指定、拡張機能とカスタムビジュアリゼーションの追加などに使用されます。

各プロジェクトに1つのマニフェストファイルのみを含めることができます。ファイル名は manifest.lkml とし、Git リポジトリのルートレベルに配置する必要があります。IDE のフォルダを使用する場合は、manifest.lkml ファイルがプロジェクトのディレクトリ構造のルートレベルに保持されていることを確認してください。

プロジェクトマニフェストファイルはプロジェクトのインポートまたはローカライズのいずれかに使用できますが、1つのファイルで両方の機能を同時に果たすことはできません。

他のプロジェクトからLookMLファイルをインポートするには、プロジェクトマニフェストファイルを使って作業中のプロジェクト名と外部プロジェクトの場所（ローカルまたはリモートの保存先）を指定します。例:

# This project
project_name: "my_project"

# The project to import
local_dependency: {
  project: "my_other_project"
}

remote_dependency: ga_360_block {
  url: "https://github.com/llooker/google_ga360"
  ref: "4be130a28f3776c2bf67a9acc637e65c11231bcc"
}

プロジェクトマニフェストファイルで外部プロジェクトを定義したら、モデルファイルの include パラメータを使用して、それらの外部プロジェクトのファイルを現在のプロジェクトに追加できます。例:

include: "//my_other_project/imported_view.view"
include: "//ga_360_block/*.view"

詳細については、他のプロジェクトからのファイルのインポートドキュメントページをご覧ください。

モデルにローカライゼーションを追加するには、プロジェクトマニフェストファイルを使ってデフォルトのローカライゼーション設定を指定します。例:

localization_settings: {
  default_locale: en
  localization_level: permissive
}

ローカライゼーションのデフォルト設定の指定は、モデルをローカライズする手順の1つです。詳細については、LookML モデルのローカライズのドキュメントをご覧ください。

Set

Looker では、セットは一緒に使用されるフィールドのグループを定義するリストです。通常、ユーザーがデータにドリルダウンした後に表示するフィールドを指定するために使用します。ドリルのsetはフィールド単位で指定されるため、ユーザーがテーブルまたはダッシュボードの値をクリックしたときに表示されるデータを制御できます。また、特定のユーザーに表示されるフィールドのグループを定義するセキュリティ機能として、Setを使用することもできます。

次の例は、ビューにセットの宣言を示しています。order_items購入したアイテムに関連する詳細情報をリストするフィールドを定義しています。setが、スコープを指定することによって、他のビューからのフィールドを参照することに注意してください。

set: order_items_stats_set {
  fields: [
    id,  # scope defaults to order_items view
    orders.created_date,  # scope is "orders" view
    orders.id,
    users.name,
    users.history,  # show all products this user has purchased
    products.item_name,
    products.brand,
    products.category,
    total_sale_price
  ]
}

セットの使用方法について詳しくは、set パラメータのドキュメントページをご覧ください。

ドリルダウン

Lookerでは、LookMLの作成時にそのように設定された任意のフィールドをドリルダウンできます。ドリルは、クエリ結果のテーブルとダッシュボードの両方で機能します。ドリルによって、クリックした値によって制限される新しいクエリが開始されます。

ドリルの動作は、ディメンションとメジャーで異なります。

ディメンションをドリルダウンすると、新しいクエリがドリルされた値でフィルタリングされます。例えば、日別の顧客の注文のクエリで特定の日付をクリックすると、新しいクエリには特定の日付の注文のみが表示されます。
メジャーをドリルダウンすると、新しいクエリには、メジャーの結果に貢献したデータセットが表示されます。例えば、カウントをドリルダウンすると、新しいクエリには、カウントの対象となった行が表示されます。最大、最小、平均のメジャーをドリルダウンすると、そのメジャーに貢献した行がすべて表示されます。たとえば、最大値をドリルダウンすると、最大値の計算に使用された 1 行だけでなく、最大値の計算に使用されたすべての行が表示されます。

新しいドリルクエリで表示するフィールドは、set で定義することも、drill_fields パラメータ（フィールドの場合）または drill_fields パラメータ（ビュー用）で定義することもできます。

派生テーブル

派生テーブルとは、クエリ結果をデータベース内の実際のテーブルのように使用できるクエリのことです。派生テーブルは、view 宣言の derived_table パラメータを使用して作成します。Lookerは、独自の列セットを持つ物理テーブルのように、派生テーブルにアクセスします。派生テーブルは、derived_table パラメータを使用して独自のビューとして公開され、従来のビューと同じ方法でディメンションとメジャーを定義します。派生テーブルのビューは、他のビューと同様、クエリしたり、他のビューに結合したりすることができます。

派生テーブルは永続的な派生テーブル（PDT）として定義することもできます。PDT は、データベースのスクラッチスキーマに書き込まれ、永続戦略で指定したスケジュールに従って自動的に再生成されます。

詳細については、Looker の派生テーブルのドキュメントをご覧ください。

データベースへの接続

LookMLプロジェクトの別の重要な要素は、Lookerがデータベースでクエリを実行するために使用するデータベース接続です。 Looker 管理者は [Connections] ページを使用してデータベース接続を構成し、LookML デベロッパーはモデルファイルの connection パラメータを使用してモデルで使用する接続を特定します。データベースから LookML プロジェクトを生成すると、Looker によってモデルファイルの connection パラメータが自動的に入力されます。