LookMLの用語と概念

このページでは、LookML を使った開発でよく遭遇する次の基本的な用語とコンセプトについて説明します。

• LookML プロジェクト
• LookML の主な構造（モデル、ビュー、Explore など）
• 派生テーブル
• データベース接続
• 大文字と小文字の区別

Look とユーザー定義のダッシュボードは、LookML を使用せずに作成するものであるため、このページでは説明しません。ただし、それらで使用されるクエリは、このページで説明する LookML の要素に依存しています。

Looker 全体で使用される用語と定義の包括的なリストについては、Looker の用語集をご覧ください。LookML プロジェクトで使用できる LookML パラメータの包括的な概要については、LookML のクイック リファレンスのページをご覧ください。

Looker と Looker Studio における類似の用語とコンセプトの違いについて詳しくは、Looker と Looker Studio の共通の用語とコンセプトのドキュメント ページをご覧ください。

LookML プロジェクト

Looker においてプロジェクトとは、SQL クエリの実行に使用されるオブジェクト、データベース接続、ユーザー インターフェース要素を記述するファイルのコレクションです。最も基本的なレベルでは、これらのファイルで、データベース テーブル同士の関係と、Looker によるテーブルの解釈方法を記述します。これらのファイルには、Looker の UI に表示されるオプションを定義または変更する LookML パラメータを含めることもできます。各 LookML プロジェクトは、バージョン管理のために、それぞれ専用の Git リポジトリに格納されます。

Looker をデータベースに接続したら、Looker プロジェクトで使用するデータベース接続を指定できるようになります。

プロジェクトには、Looker の [Develop] メニューからアクセスできます（詳細とその他のオプションについては、プロジェクト ファイルへのアクセスをご覧ください）。

新しいプロジェクトの作成については、モデルの生成のドキュメント ページをご覧ください。また、既存の LookML プロジェクトへのアクセスと変更については、プロジェクト情報へのアクセスと編集のドキュメント ページをご覧ください。

プロジェクトの構成要素

図に示すように、LookML プロジェクト内の一般的なファイルの種類には次のものがあります。

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

注: Looker では、「explore」という単語は、密接に関連する 2 つの要素のいずれかを指します。explore（ドキュメント全体でコードフォントで表記）は、モデルファイル内でクエリ オプションを定義するために使用する LookML パラメータです。Explore（ドキュメント全体で大文字で表記）は Looker 内のインタラクティブなページであり、フィールドを選択したり、フィルタを適用したり、プロジェクトのファイル内で設定されているオプションを選択したりして SQL クエリを作成できます。

モデル、ビュー、Explore、マニフェストの各ファイルに加えて、組み込みダッシュボード、ドキュメント、ローカライズなどに関連する他の種類のファイルをプロジェクトに含めることもできます。ここに示したファイルの種類と、LookML プロジェクトに含めることができるその他のファイルの種類の詳細については、LookML プロジェクトのファイルのドキュメント ページをご覧ください。

これらのファイルによって、1 つのプロジェクトが構成されます。バージョン管理に Git を使用している場合、通常は各プロジェクトをそれぞれ専用の Git リポジトリにバックアップします。

LookML のプロジェクトとファイルはどうやって作成するか

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

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

• 複数のビューファイル。それぞれデータベース内の個々のテーブルに対応します。
• 1 つのモデルファイル。モデルファイルでは、ビューごとにそれぞれ 1 つの Explore が宣言されます。それぞれの Explore の宣言には join ロジックが含まれます。このロジックにより、Looker がこの Explore に関連していると判断する任意のビューが結合されます。

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

LookML の主な構造

プロジェクトの構成要素の図に示すように、プロジェクトには通常、1 つ以上のモデルファイルが含まれます。モデルファイルには、モデルとその Explore および結合を定義するパラメータが含まれます。さらに、プロジェクトには通常、1 つ以上のビューファイルが含まれます。それぞれのビューファイルには、ビュー、ビューのフィールド（ディメンションとメジャーを含む）、フィールドセットを定義するパラメータが含まれます。また、プロジェクトには、プロジェクト レベルの設定が可能なプロジェクト マニフェスト ファイルを含めることもできます。このセクションでは主な構造について説明します。

モデル

モデルとは、データベースへのカスタマイズされた入り口であり、ビジネス ユーザーに対して直観的なデータ探索の方法を提供します。1 つの LookML プロジェクトで、同じデータベース接続に対して複数のモデルが存在してもかまいません。この場合、各モデルは異なるデータを異なるユーザーに公開することができます。たとえば、販売担当者と会社の役員では異なるデータが必要になるため、2 つのモデルを開発し、各ユーザーに適したデータベースへのビューを提供することができます。

1 つのモデルは、1 つのデータベースへの接続を指定します。デベロッパーはモデルファイル内でモデルの Explore も定義します。デフォルトでは、Explore は定義されているモデル名の下に編成されます。ユーザーは [Explore] メニューでモデルのリストを確認できます。

モデルファイルの詳細については、LookML プロジェクトのファイルの種類のドキュメント ページをご覧ください。モデルファイルの構造と一般的な構文についても説明しています。

モデルファイルで使用できる LookML パラメータの詳細については、モデル パラメータのドキュメント ページをご覧ください。

ビュー

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

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

デフォルトでは、Explore データテーブルのディメンション名とメジャー名の先頭にはビュー名が付きます。この命名規則により、フィールドが属するビューが明確になります。次の例では、データテーブルのフィールド名の前に Orders と Users というビュー名が表示されています。

ビューファイルの詳細については、LookML プロジェクトのファイルの種類のドキュメントをご覧ください。ビューファイルの構造と一般的な構文についても説明しています。

ビューファイルで使用できる LookML パラメータの詳細については、ビュー パラメータのドキュメント ページをご覧ください。

Explore

Explore は、ユーザーがクエリできるビューです。Explore は、クエリの開始点、SQL の用語では SQL ステートメントの FROM と考えることができます。すべてのビューが関心のあるエンティティを表すわけではないので、すべてのビューが Explore であるとは限りません。たとえば、州名のルックアップ テーブルに対応する States ビューは、ビジネス ユーザーが直接クエリすることはないため、Explore を必要としません。一方、Orders（注文）ビューは、ビジネス ユーザーがクエリする方法を必要とする可能性が高いため、Orders 用の Explore を定義することは理にかなっています。ユーザーが Explore を操作してデータをクエリする方法については、Looker での Explore の表示と操作のドキュメント ページをご覧ください。

ユーザーは、Looker の [Explore] メニューで Explore のリストを確認できます。Explore は、属しているモデル名の下に表示されます。

慣例では、Explore はモデルファイル内で explore パラメータを使用して宣言されます。次のモデルファイルの例では、e コマース データベースの orders Explore を定義しています。explore 宣言内で参照している orders と customers の各ビューは、このファイルではなく、それぞれのビューファイルで定義されています。

connection: order_database
include: "filename_pattern"

explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

この例では、connection パラメータを使用してモデルのデータベース接続を指定し、include パラメータを使用してモデルが参照できるファイルを指定しています。

この例の explore 宣言では、ビュー間の結合関係も指定しています。join 宣言の詳細については、このページの結合に関するセクションをご覧ください。join パラメータで使用できる LookML パラメータの詳細については、結合パラメータのドキュメント ページをご覧ください。

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

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

Looker では、ディメンションはグループ化可能なフィールドであり、クエリ結果のフィルタに使用できます。ディメンションは以下のいずれかとなります。

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

Looker が生成する SQL の GROUP BY 句には必ずディメンションが含まれます。

たとえば、Products ビューのディメンションには、製品名、製品モデル、製品の色、製品価格、製造年月日、販売終了日などが含まれます。

メジャーは、SQL 集計関数（COUNT、SUM、AVG、MIN、MAX など）を使用するフィールドです。他のメジャー値の値に基づいて計算されるフィールドもメジャーです。メジャーを使用して、グループ化された値をフィルタできます。たとえば、Sales ビューのメジャーには、アイテム総販売数（count）、総売上高（sum）、平均売上高（average）などが考えられます。

フィールドの動作と想定される値は、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 フィールドを定義することもできます。

フィールドの宣言とそれに適用できる各種設定の詳細については、フィールド パラメータのドキュメント ページをご覧ください。

結合

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

explore 宣言内の結合の例を次に示します。

# 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 つのプロジェクトで使用できるマニフェスト ファイルは 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 モデルのローカライズのドキュメント ページをご覧ください。

セット

Looker では、セットは一緒に使用するフィールドのグループを定義するリストです。セットは通常、ユーザーがデータをドリルダウンした後にどのフィールドを表示するかを指定するために使用します。ドリルセットはフィールド単位で指定されるため、ユーザーがテーブルまたはダッシュボードの値をクリックしたときに表示されるデータを完全に制御できます。また、特定のユーザーに表示されるフィールドのグループを定義するセキュリティ機能としてセットを使用することもできます。次の例は、ビュー order_items でのセットの宣言を示しています。購入されたアイテムの詳細を一覧表示するフィールドを定義しています。スコープを指定することによって、セットが他のビューのフィールドを参照していることに注目してください。

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 では、ユーザーがデータをさらにドリルダウンできるようにフィールドを構成できます。ドリルは、クエリ結果の表とダッシュボードの両方で機能します。ドリルによって、クリックした値によって制限される新しいクエリが開始されます。

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

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

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

派生テーブル

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

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

詳しくは、Looker の派生テーブルのドキュメント ページをご覧ください。

データベース接続

LookML プロジェクトのもう 1 つの重要な要素としてデータベース接続があります。Looker はこのデータベース接続を使用して、データベースに対してクエリを実行します。Looker 管理者は [Connections] ページを使用してデータベース接続を構成します。LookML デベロッパーは、モデルファイル内で connection パラメータを使用して、モデルで使用する接続を指定します。データベースから LookML プロジェクトを生成した場合、モデルファイルの connection パラメータが Looker によって自動的に設定されます。

大文字と小文字の区別

LookML では大文字と小文字が区別されるので、LookML 要素を参照するときは大文字と小文字が一致している必要があります。存在しない要素を参照すると、Looker で警告が表示されます。

たとえば、e_flights_pdt という Explore があり、LookML デベロッパーが誤った表記（e_FLIGHTS_pdt）でその Explore を参照したとします。この例では、Explore e_FLIGHTS_pdt が存在しないという警告が Looker IDE に表示されます。また、存在している Explore の名前（e_flights_pdt）が候補として表示されます。

プロジェクトに e_FLIGHTS_pdt と e_flights_pdt の両方が含まれている場合は、Looker IDE が誤りを指摘できないため、使用する人が意図したほうを使用しているかを確認する必要があります。通常、LookML オブジェクトの名前はすべて小文字にすることをおすすめします。

IDE のフォルダの名前でも大文字と小文字が区別されます。ファイルのパスを指定するときは、フォルダ名の大文字と小文字を一致させる必要があります。たとえば、Views という名前のフォルダがある場合は、include パラメータでも同じように大文字と小文字を使い分けてください。プロジェクト内の既存のフォルダと大文字 / 小文字が一致しない場合は、Looker IDE にエラーが表示されます。