ディメンショナルモデリングとは？：dbt×BigQueryを使ったデータモデリング入門

2023年11月9日

この記事では、BigQueryとdbt(Data Build Tool)Cloudを使用してデータモデリングにおけるディメンショナルモデリングの基本について解説しています。

はじめに

データモデリングはデータウェアハウス設計の根幹をなすプロセスであり、データサイエンティストが分析をスムーズに進めていくための重要なテクニックです。今回の記事では、BigQueryとdbt(Data Build Tool)Cloudを使用してデータモデリングにおけるディメンショナルモデリングの基本について解説します。

ディメンショナルモデリングとは？

ディメンショナルモデリングは、データを「事実（Fact）」と「次元（Dimension）」に分けて組織化する手法です。このモデルは、特にデータウェアハウスの設計に適しています。

事実テーブル: 事実テーブルは、ビジネスプロセスの量的側面を捉え、売上、数量、利益などの計測可能なデータを含みます。
次元テーブル: 次元テーブルは、事実テーブルの計測値を「誰が」「何を」「いつ」「どこで」などの文脈で説明します。これには顧客名、日付、製品情報などの記述的なデータが含まれます。

ディメンショナルモデリングの利点について

ディメンショナルモデリングには以下のような利点があります。

分析の容易さ: 分析者が理解しやすい形式でデータが整理されるため、データの探索やレポート作成が容易になります。
クエリパフォーマンス: 適切に設計されたディメンショナルモデルは、データベースのクエリパフォーマンスを向上させることができます。
柔軟性: 新しいデータ源の統合や変更がしやすく、ビジネスの変化に対応する柔軟性を持っています。

BigQuery上でテーブルを作成

まずはBigQuery上にデータを格納するための適当なテーブルを用意、または作成します。今回は以下のような架空のEコマーストランザクションデータのテーブルを作成してみました。

事実テーブルモデルの作成

ここからはdbt Cloud上で作業を行います。

dbt Cloudの詳細はdbt Cloudxbigqueryの実践をご参照ください。

まずmodels配下にfact_transactions.sqlファイルを作成します。

事実テーブルはビジネスイベントを数値で捉えるための中心的なテーブルです。これには通常、数量や価格などのメトリックスと、それらが発生した時間や関連する次元のキーが含まれます。以下のfact_transactionsモデルでは、トランザクションごとの詳細な情報を記載しています。

ファクトテーブルモデル（fact_transactions.sql）

{{ config(materialized='table') }}

WITH source_data AS (
SELECT
TransactionID,
TransactionDate,
CustomerName,
ProductName,
Quantity,
UnitPrice,
TotalPrice,
PaymentMethod
FROM {{ source('data_test', 'ecommerce_transactions') }}
)

SELECT
TransactionID,
TransactionDate,
CustomerName,
ProductName,
Quantity,
UnitPrice,
TotalPrice,
PaymentMethod
FROM source_data

次元テーブルモデルの作成

次元テーブルは、ビジネスプロセスの文脈を提供するための補助的なテーブルです。ここでは、顧客、製品、支払い方法などの属性に焦点を当てます。次元テーブルは通常、非常に記述的であり、分析者が簡単に理解できるような情報を含んでいます。

顧客ディメンションモデル (dim_customers.sql)

{{ config(materialized='table') }}

WITH source_data AS (
SELECT DISTINCT
CustomerName
FROM {{ source('data_test', 'ecommerce_transactions') }}
)

SELECT
ROW_NUMBER() OVER (ORDER BY CustomerName) AS CustomerID,
CustomerName
FROM source_data

商品ディメンションモデル (dim_products.sql)

{{ config(materialized='table') }}

WITH source_data AS (
SELECT DISTINCT
ProductName,
UnitPrice
FROM {{ source('data_test', 'ecommerce_transactions') }}
)

SELECT
ROW_NUMBER() OVER (ORDER BY ProductName) AS ProductID,
ProductName,
UnitPrice
FROM source_data

支払方法ディメンションモデル(dim_payment_methods.sql)

{{ config(materialized='table') }}

WITH source_data AS (
SELECT DISTINCT
PaymentMethod
FROM {{ source('data_test', 'ecommerce_transactions') }}
)

SELECT
ROW_NUMBER() OVER (ORDER BY PaymentMethod) AS PaymentMethodID,
PaymentMethod
FROM source_data

モデルの依存関係について

モデル間の依存関係を定義することで、dbtはモデルをどの順番でビルドすべきかを自動的に理解します。fact_transactions モデルは dim_customers、dim_products、dim_payment_methods モデルに依存しています。

以下のようなLineageになっていれば問題ありません。