LookMLの用語と概念

このページでは、LookML の開発時によく見られる以下の基本用語とコンセプトを定義します。

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

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 プロジェクトへのアクセスと変更の情報については、プロジェクト情報へのアクセスと編集をご覧ください。

プロジェクトの各部

図に示すように、LookML プロジェクトでプロジェクトで最も一般的なファイルの種類は次のとおりです。

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

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

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

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

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

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

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

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

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

主なLookML構造体

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

モデル

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

モデルは、単一のデータベースへの接続を指定します。デベロッパーはモデルファイル内でモデルの Explore も定義します。デフォルトでは、Explore は定義されているモデル名で整理されます。[Explore] メニューにモデルが一覧表示されます。

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

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

表示

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

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

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

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

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

探索

Exploreは、ユーザーがクエリできる画面です。Explore はクエリの開始点、SQL 用語では SQL ステートメントの FROM です。すべてのビューが関心のあるエンティティを表すわけではないので、すべてのビューがExploreであるとは限りません。たとえば、州名のルックアップ テーブルに対応する States ビューでは、ビジネス ユーザーは直接クエリを行う必要がないため、Explore は保証されません。一方、ビジネス ユーザーはおそらくオーダー ビューをクエリする方法を必要とするため、オーダー用の 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 では、ディメンションは必ず、Looker が生成する SQL の GROUP BY 句に表示されます。

たとえば、商品ビューのディメンションには、商品名、商品モデル、商品の色、商品価格、商品の作成日、商品のサポート終了日などが含まれます。

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

フィールドの動作と予期される値は、string、number、time など、宣言されたタイプによって異なります。measure では、タイプには 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 宣言での結合の例を次に示します。

# 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 モデルのローカライズのドキュメント ページをご覧ください。

セット

Looker では、セットは一緒に使用されるフィールドのグループを定義するリストです。通常、セットは、ユーザーがデータにドリルダウンした後に表示するフィールドを指定するために使用されます。ドリルのsetはフィールド単位で指定されるため、ユーザーがテーブルまたはダッシュボードの値をクリックしたときに表示されるデータを制御できます。また、特定のユーザーに表示されるフィールドのグループを定義するセキュリティ機能として、Setを使用することもできます。次の例は、ビュー order_items 内の set 宣言で、購入したアイテムに関連する詳細情報をリストするフィールドを定義しています。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 の使用方法の詳細については、set パラメータのドキュメント ページをご覧ください。

ドリルダウン

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

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

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

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

派生テーブル

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

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

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

データベースへの接続

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

大文字と小文字の区別

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

たとえば、e_flights_pdt という Explore があり、LookML デベロッパーが正しくない大文字表記（e_FLIGHTS_pdt）を使用してその Explore を参照するとします。この例では、Explore e_FLIGHTS_pdt が存在しないという警告が Looker IDE に表示されています。また、IDE から既存の Explore の名前（e_flights_pdt）が提案されています。

プロジェクトに e_FLIGHTS_pdt と e_flights_pdt の両方が含まれている場合は、Looker IDE が修正できないため、どのバージョンを使用するかを確認する必要があります。通常、LookMLオブジェクトの名前には小文字を使用することをお勧めします。

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