スタースキーマとキューブ

ここまでの記事で多次元データモデルの利用背景についてみてきました。ここからは以下の具体的なトピックを扱っていきます。

ディメンションテーブル
ファクトテーブル
緩やかに変化するディメンション(slowly changing dimensions)
キューブ

ディメンションテーブル

ディメンションテーブルについては分析システムにおける多次元データモデル(2)において概要は紹介しています。ディメンションテーブルは「分析の目的」そのものであって、多様な分析を可能にするためには多くのテーブル列を持つのが一般的です。

サロゲートキーとナチュラルキー

分析システムにおける多次元データモデル(3)で紹介したスタースキーマをもう一度見てみます。

f:id:good-value:20170202233353p:plain

このER図の中央にあるのがファクトテーブル、ファクトテーブルの外側に位置するのがディメンションテーブルです。このファクトテーブルとディメンションテーブルの結合キーについて業務システムとは異なる概念が必要となります。

業務システムにおいてはマスタデータの行を特定するための主キー(PrimaryKey)は業務的に意味がある属性を利用します。先ほどの図で言うところの商品ID、注文日、顧客ID、販売担当者IDがそれに該当します。この業務的に意味のあるキーのことをナチュラルキーと呼びます。データウェアハウスにおいてはこのナチュラルキーは使用せずに、それとは別のユニークキーを利用するのが一般的です。このキーのことをサロゲートキーと呼びます。スタースキーマにデータをロード(ETL)する際に発番されます。このサロゲートキーは数値型であることが一般的で業務的には全く意味の持たない値です。ディメンションテーブルにおいてサロゲートキーはユニークな値を持ちます。

図においてサロゲートキーについては「SK」と表示して列名を"_key"とします。ナチュラルキーは「NK」と表示します。業務的に意味があるナチュラルキーは業務システムにおいて複数列で表現される場合もあるので、複数列を持つ場合もあります。サロゲートキーはデータ生成元（通常は業務システム）で変化があった場合のデータ分析を可能とするためのものでユニークな値を持ちます。データ生成元においてナチュラルキーの変更はたびたび発生します。ディメンションテーブルはナチュラルキーではなくサロゲートキーを使って行を特定することからデータ生成元では対応できない、データの履歴を扱うことができます。

例えば受注システムにおいて顧客ID:404777の住所を管理していたとします。この時、顧客の引っ越しに伴う住所変更を行うと、住所変更前の住所でのデータ分析が出来なくなってしまいます。ここでサロゲートキーを利用していると住所変更前と後のデータを保持することができることから時系列のデータ分析が可能となります。この時のサロゲートキーは一つの列で定義したユニーク値です。この一つの列というのが重要です（後述）。

もう一つの方法として、ナチュラルキーにバージョンを持つ方法があります。[顧客ID + バージョン]の2つの列でユニーク値にするという方法です。これでも履歴を持つことができるため履歴を扱うという問題はクリアすることになります。ここで注意するのは、ディメンションテーブルの主キーはファクトテーブルと結合するためのキーであるということです。ディメンションテーブルの主キーを[顧客ID + バージョン]とした場合、ファクトテーブルにおいても2つの列を保持することになります。これはデータを扱ううえでの複雑さが増す（常に結合では2つの列を指定する必要がある）ことから望ましくありません。当然、顧客IDだけを指定した場合は値は重複されて計算されてしまいまい、バグのもとにもなります。

さらに別の方法として、ナチュラルキーにタイムスタンプを付与する方法があります。[顧客ID + タイムスタンプ]の2つ列でユニーク値を持ちます。こちらについての欠点もバージョンを持つ場合と変わりません。

「できるからやる」ではなく、設計時にこのようなデータウェアハウスにおけるデータモデルの基礎を理解したうえで方針をたてて徹底することがいかに大事かというのを示しているともいえます。

（つづく）