ディメンショナルモデリングとは？スター/スノーフレークスキーマでDWHを設計する手法

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

ディメンショナルモデリング（Dimensional Modeling）とは、データウェアハウス（DWH）やBIシステムにおいて、分析用データベースを設計するための手法です。ラルフ・キンボール（Ralph Kimball）が1996年の著書「The Data Warehouse Toolkit」で体系化しました。業務システムのデータベース設計に用いられる正規化モデル（第3正規形）とは異なり、「人間が直感的に理解でき、クエリのパフォーマンスが高い」ことを設計の最優先事項としています。

ディメンショナルモデリングの基本構造は、ビジネスプロセスの計測値を格納する「ファクトテーブル」と、ファクトを分析する切り口を提供する「ディメンションテーブル」の2種類のテーブルで構成されます。この構造がスタースキーマ（星型スキーマ）と呼ばれるのは、中央のファクトテーブルを複数のディメンションテーブルが取り囲む形がER図上で星の形に見えるためです。

コンサルタントがデータ活用戦略やBI基盤構築を支援する際、ディメンショナルモデリングの理解は不可欠です。正規化モデルのまま分析しようとすると、複雑なJOINが必要になり、パフォーマンスが低下し、ビジネスユーザーが自力でデータにアクセスできなくなります。

構成要素

ファクトテーブル（Fact Table）

ファクトテーブルは、ビジネスプロセスの計測値（メジャー）を格納するテーブルです。売上金額、数量、コストなどの数値データと、ディメンションテーブルへの外部キー（FK）で構成されます。ファクトテーブルは一般的にデータ量が最も大きく、DWH全体のストレージの90%以上を占めることもあります。

ファクトには3つの種類があります。加法的ファクト（すべてのディメンションで集計可能）、半加法的ファクト（一部のディメンションでのみ集計可能）、非加法的ファクト（集計不可能な比率や割合）です。

ディメンションテーブル（Dimension Table）

ディメンションテーブルは、ファクトを分析するための「切り口」を提供するテーブルです。日付、商品、店舗、顧客など、ビジネスユーザーが「○○別に見たい」と要求する属性情報を格納します。ディメンションテーブルは行数が比較的少なく、列数が多いワイドテーブルになる傾向があります。

スタースキーマとスノーフレークスキーマ

スキーマ種別	構造	メリット	デメリット
スタースキーマ	ディメンションを非正規化	クエリが単純、高パフォーマンス	ストレージ効率がやや低い
スノーフレークスキーマ	ディメンションを正規化	ストレージ効率が高い	JOINが増えクエリが複雑

実務ではスタースキーマが推奨されることが多いです。現代のストレージコストは低下しており、ストレージ効率よりもクエリの単純さとパフォーマンスが優先されます。

SCD（Slowly Changing Dimension）

ディメンションの属性は時間とともに変化します。顧客の住所変更、商品カテゴリの再編成などに対応するために、SCDのタイプ1（上書き）、タイプ2（履歴保持）、タイプ3（前回値と現在値を保持）のいずれかを選択します。

実践的な使い方

ステップ1: ビジネスプロセスを選択する

ディメンショナルモデリングの最初のステップは、モデル化するビジネスプロセスの選択です。「売上」「在庫」「出荷」「顧客対応」など、組織のビジネスプロセスからスタートします。複数のプロセスを一度にモデル化しようとせず、最も分析ニーズが高いプロセスから着手することが推奨されます。

ステップ2: 粒度（Grain）を宣言する

モデリングで最も重要な判断が粒度の宣言です。ファクトテーブルの1行が「何を表すか」を明確に定義します。「1日あたり1店舗あたり1商品の売上」「1トランザクション明細」「1月あたり1顧客の残高」など、粒度を曖昧にすると後工程で致命的な設計ミスにつながります。粒度は可能な限り細かくすることが原則です。粗い粒度から細かい粒度に変更するのは困難ですが、細かい粒度を集計するのは容易だからです。

ステップ3: ディメンションを特定する

宣言した粒度に基づいて、ファクトを分析する切り口（ディメンション）を特定します。「いつ」「何を」「どこで」「誰が」「どうやって」という問いに答える形でディメンションを洗い出します。このステップではビジネスユーザーとの対話が不可欠です。分析者が「○○別に見たい」と言う「○○」がディメンション候補です。

ステップ4: ファクトを特定する

宣言した粒度で計測可能な数値（メジャー）を特定します。売上金額、数量、割引額、原価など、ビジネスプロセスで発生する計測値をファクトテーブルに定義します。ファクトは可能な限り加法的であることが望ましいです。

活用場面

• BI基盤構築: 全社的なBIプラットフォームのデータモデルとしてスタースキーマを採用し、ビジネスユーザーのセルフサービス分析を実現します
• データマート設計: 部門別・テーマ別のデータマートをディメンショナルモデルで設計し、分析の即応性を高めます
• KPIダッシュボード: 経営ダッシュボードの裏側のデータ構造として、ファクトとディメンションの組み合わせでKPIを定義します
• データ移行プロジェクト: レガシーシステムからの移行時に、正規化された業務データをディメンショナルモデルに変換します
• クラウドDWH導入: Snowflake、BigQuery、Redshiftなどのクラウドデータウェアハウスの論理設計に適用します

注意点

粒度の宣言を曖昧にしない

粒度の宣言が不十分なまま設計を進めると、異なる粒度のデータが混在するファクトテーブルができあがります。集計結果の二重カウントや不整合が発生し、ユーザーの信頼を失います。粒度は1文で明確に記述し、チーム全員の合意を得ます。

過度な非正規化を避ける

スタースキーマの利点は非正規化による単純さですが、過度に非正規化するとデータ整合性の維持が困難になります。特に頻繁に更新される属性を多数のテーブルにコピーすると、更新漏れやデータ不整合のリスクが高まります。

業務システムのER図をそのまま使わない

正規化された業務システムのER図をDWHの設計にそのまま流用するのは、ディメンショナルモデリングの典型的なアンチパターンです。業務システムはトランザクション処理に最適化された設計であり、分析用途には適しません。

SCD戦略を事前に決定する

ディメンションの変更履歴をどう扱うかは、ビジネス要件に依存します。過去のレポートを当時の状態で再現する必要があるか、最新状態での分析のみで十分かによって、SCDのタイプが異なります。この決定を後回しにすると、データの再構築が必要になります。

まとめ

ディメンショナルモデリングは、ファクトテーブル（計測値）とディメンションテーブル（分析の切り口）で構成するスタースキーマを中核としたDWH設計手法です。ビジネスプロセスの選択、粒度の宣言、ディメンションとファクトの特定という4ステップで設計を進めます。コンサルタントは、クライアントのデータ活用基盤構築において、ビジネスユーザーが直感的に理解でき、高いクエリパフォーマンスを実現するデータモデルを設計するために、この手法を活用できます。