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

 

　ディメンショナル・モデル（Dimensional Model）は、データウェアハウスやビジネスインテリジェンス（BI）システムのためのデータモデリング手法の一つです。このモデリング手法は、データを分析しやすく、理解しやすい形式で整理することを目的としています。ディメンショナルモデルは、主に「ディメンション」と「ファクト」の二つの要素で構成されます。

ディメンション

 

　ディメンションは、後述する「ファクト」で定義された数値データを分析する際に用いる参照軸を定義します。これには、日付、製品、地域、顧客など様々な分析要素が含まれます。

　例えば、商品ディメンションの概念スキーマのサンプルとして、次の図のようなものが考えられます。この階層構造はユーザーが分析時に深堀り（ドリルダウン）を行う際のパスや、その際の探索順序を示しています。また、設計者がデータベースの論理設計にフェーズを進めるための属性情報も付記します。（下表）

[商品ディメンション]

[商品ディメンション：従属属性]

階層	従属属性	データ型	表示	検索	整列	サンプル
商品合計	商品合計	文字	〇			商品合計
クラス	クラスコード	文字	〇	〇	〇	A,B
	クラス名称	文字	〇	〇		家電,パソコン
	クラス英語名称	文字	〇	〇		consumer electronics,PC
	クラス表示順序	整数			〇	1,2
サブクラス	：	：	：	：

ファクト

 

　ファクトは、ビジネスプロセスの量的データ（例：売上、コスト、数量など）を記録します。これらのデータは、分析の対象となる数値で、「メジャー（Measures）」または「ファクト（Facts）」と呼ばれます。ファクトは、ディメンションとの関連付けにより定義されます。

　例えば、売上実績ファクト、売上予算ファクトの概念スキーマのサンプルとして、下図のようなものが考えられます。関連するディメンションとの関係、およびその粒度が示されます。例えば、売上実績は商品（単品）の細かさで発生しますが、売上予算は商品サブカテゴリの細かさで定義されます。

[売上実績]と[売上予算]のファクト定義

ディメンショナルモデルからのデータベース論理設計

 

スタースキーマ

 

　ディメンショナルモデルの基本的な実装設計であり、中心にファクトテーブルを配置し、その周囲にディメンションテーブルを配置することにより、星（スター）のような形になることからそう呼ばれています。この設計により、クエリのパフォーマンスが向上し、データの理解が容易になります。ディメンションとファクトはサロゲートキー（後述）と呼ばれるソースシステムのナチュラルキーとは異なるキーで結合されます。

 

 

 

スノーフレークスキーマ

 

　スノーフレークスキーマは、スタースキーマをさらに正規化した構造で、ディメンションテーブルが複数のテーブルに分割されます。これにより、データの冗長性が減少します。

 

ディメンションテーブル

 

　ディメンションテーブルは、概念スキーマにおける「ディメンション」をテーブルとして実体化したものです。スタースキーマやスノーフレークスキーマにおけるディメンションのように、必要な参照軸、検索軸、整列軸を定義します。検索軸や整列軸として指定されたカラムは、インデックスの付与対象候補となります。

 

ファクトテーブル

 

　ファクトテーブルは、概念スキーマにおける「ファクト」をテーブルとして実体化したものです。スタースキーマやスノーフレークスキーマにおけるファクトのように、ディメンションと結合するための外部キーと、ビジネスプロセスの量的データ（例：売上、コスト、数量など）、及び、ディメンションを持たないディメンションであるDD（Degenerate dimension：注文番号など）を保持します。外部キー、及び、検索軸や整列軸として指定されたカラムは、インデックスの付与対象候補となります。

サロゲートキー

 

　サロゲートキーは、スタースキーマやスノーフレークスキーマのディメンションの主キーとしてマスタのナチュラルキーとは別に定義されます。サロゲートキーの利用により次のような利点があります。

• 変更管理の制御 後述の「Slowly Changing Dimensions: SCD」により、ディメンションの属性値の変更を柔軟に制御、追跡することが可能となります。

• データ粒度の制御 単一のディメンションに最小粒度の異なる階層のデータを格納することができます。上述のサンプル「売上実績」と「売上予算」のモデルは実績と予算で発生するデータの粒度が異なりますが、共通のディメンション（Conformed Dimensions）でファクト横断的な分析が可能となります。

• 異なるデータソースからのデータの統合 コード体系の異なるデータソースから連携されたデータを容易に一元化することが可能です。

• 性能の維持 一般に、サロゲートキーは連続する整数値で生成されることが多く、文字列型のナチュラルキーと比較して物理的なデータ長を削減できます。この結果、ファクトテーブルのレコード長が短くなり、クエリ実行時のI/Oコストが低減し、全体の性能が向上するケースが多くあります。

• ナチュラルキー再利用の対策 現在は減少していますが、過去には汎用機やその後継システムにおいて、ソースデータのナチュラルキー（組織コードや商品コードなど）が、異なるエンティティインスタンスのキーとして再利用されることがありました。このような状況に対しても、サロゲートキー及び後述のデュラブルキーの利用によりデータを柔軟に格納し、活用することが可能です。

Slowly Changing Dimensions: SCD

 

　SCDは、時間経過とともに発生するディメンション属性の変更をと追跡するための手法です。SCDには複数のタイプがあります。ディメンショナルモデリングが提唱された当時（1980年代後半）のSCDのタイプは1～3でしたが、現在では0～7と様々なケースに柔軟に対応ができるように拡張が施されています。

　ここで、以下のサンプルで使用する用語の定義を確認しておきます。

用語	説明	サンプルでの表記例
ナチュラルキー	ソースデータから連携されるキー項目	商品コード
サロゲートキー	ディメンショナル・モデルでディメンションを一意に識別するキー項目	商品キー
デュラブルキー	ナチュラルキーに対応してディメンショナル・モデルで独立して付与されるキー	商品-D-キー

SCD Type 1～3は初期のディメンショナルモデルから存在する基本的なSCDタイプです。

次のデータを想定して説明します。

 

現在（2024/2/21）の商品ディメンション

 

2/22の変更データ（価格が200円から240円に変更された場合）

 

• SCD Type 1（履歴なし） 既存のレコードを上書きし、過去の履歴データは保持しません。

 

• SCD Type 2（履歴レコード） ディメンションテーブル内のデータが変更された場合、新しいレコードを追加して変更履歴を保持します。各レコードには有効期間が設定されます。

 

• SCD Type 3（履歴カラム） ディメンションテーブル内の変更を追跡するために、新しい属性（列）を追加します。通常、現在の値と前の値を保持するための2つの属性が使用されます。

 

 

SCD Type 0およびType 4からType 7は、後に追加されたSCD（Slowly Changing Dimensions）のタイプです。

 

• SCD Type 0（オリジナルの保持、不変） ディメンションの属性値が変更されないディメンションです。期間ディメンションなどがこれにあたります。

 

• SCD Type 4（ミニディメンション） SCDは「ゆるやかに変化する」属性の管理を行う手法ですが、ディメンションの属性の中には「頻繁に変化する」特性をもつ属性（Frequently Changing Dimensions）があります。その場合は、その属性を独立したディメンションテーブルに分離し、個別のサロゲートキーを付番し、ファクトと紐づけます。例えば、商品原価が頻繁に変更される想定の商品ディメンションは下図のよう分割された構成に設計されます。



商品ディメンション、商品原価（ミニ）ディメンションにはそれぞれ次のようにデータが充填されます。



 

• SCD Type 5（ミニディメンション＋Type-1補足）
SCD Type 4に加えて、最新のミニディメンション（FCD）の値をType-1方式でSCDに反映しておく設計です。



 

• SCD Type 6（ハイブリッド） タイプ1,2,3の特徴を組み合わせたハイブリッド型のディメンションです。変更履歴の追跡可能で、かつ、最新のデータが保持されます。

 

• SCD Type 7（type-1,2のデュアルディメンション） Type-2ディメンションテーブルにデュラブルキーを追加し、ファクトテーブルにはサロゲートキーとデュラブルキーの双方を定義します。履歴参照時はサロゲートキーでファクトテーブルと結合します。最新値参照時はデュラブルキーでファクトテーブルと結合し、ディメンションの最新値に絞り込みます。

 

　初期のディメンショナルモデリングでは、ナビゲーションブリッジテーブル（NBT）を使用してディメンションの属性変化を追跡するアプローチが採用されていました。しかし、現在では豊富なSCD（Slowly Changing Dimensions）のバリエーションにより、属性変化の参照をシンプルかつ効率的に制御することが可能になりました。

 

　このように、ディメンショナルモデルは、手法の改良を重ねながら日々進化し、より使いやすく効率的な手法へと成長しています。

• The Data Warehouse Toolkit, 3rd Edition 2013 Ralph Kimball, Margy Ross

• The Data Warehouse Lifecycle Toolkit, 2nd Edition Ralph Kimball, Margy Ross