表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

このページは Cloud Translation API によって翻訳されました。

LookMLの用語と概念

このページでは、LookML の開発でよく見かける次のコア用語とコンセプトを定義します。

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

ルックとユーザー定義のダッシュボードは、ユーザーが 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 ダッシュボードを含めることができます。それぞれが他の LookML 要素で構成されます。

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

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

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

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

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

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

新しいプロジェクトをデータベースから生成する場合、プロジェクトを作成するためのテンプレートとして使用できる、以下のファイルのベースラインが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 というビュー名が表示されています。

[注文作成日]、[ユーザー ID]、[注文数] フィールドが選択されているサンプルクエリのデータテーブル。

ビューファイルの構造と一般的な構文などのビューファイルの詳細については、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 ファイルがプロジェクトのディレクトリ構造のルートレベルに保持されていることを確認してください。

他のプロジェクトから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はフィールド単位で指定されるため、ユーザーがテーブルまたはダッシュボードの値をクリックしたときに表示されるデータを制御できます。また、特定のユーザーに表示されるフィールドのグループを定義するセキュリティ機能として、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 の使用方法の詳細については、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はエラーを表示します。

Looker IDE により表示されている、インクルードがどのファイルとも一致しないという警告。