LookMLの用語と概念

このページでは、LookML の開発中に頻繁に発生する可能性のある、次の主な用語とコンセプトを定義します。

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

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

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

LookML プロジェクト

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

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

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

新しいプロジェクトの作成については、新しい LookML プロジェクトの作成をご覧ください。また、既存の LookML プロジェクトへのアクセスと変更の情報については、プロジェクト情報へのアクセスと編集をご覧ください。

プロジェクトの各部

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

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

注: Looker では、探索は 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であるとは限りません。たとえば、都道府県名のルックアップ テーブルに対応する [State] ビューは、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 では、ディメンションは常に Looker が生成する SQL の GROUP BY 句に表示されます。

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

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

フィールドの動作と想定値は、宣言された型（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 宣言の結合例を次に示します。

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

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

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

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

派生テーブル

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

派生テーブルは永続的な派生テーブル（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はエラーを表示します。