スター スキーマによるデータ ウェアハウス設計

Spectrum™ Technology Platform は、スター スキーマ設計を使用したデータ ウェアハウスの作成とメンテナンスをサポートしています。スター スキーマでは、イベントの具体的な記述であるファクト、またはファクト テーブルでのファクトの記述であるディメンション属性のどちらかとしてデータが保存されます。ファクトは定期的に変化しますが、ディメンションはゆっくりと変化するか、またはまったく変化しません。

次の図に、スター スキーマの設計を示します。



この図には、スター スキーマの主な特徴である、ファクト テーブル、ディメンション テーブル、および結合が示されています。

ファクト テーブル

ファクト テーブルは、データ ウェアハウスのスター スキーマで中心となるテーブルです。通常、ファクト テーブルには、特定のイベントを記述する数値的または定量的な情報 (尺度と呼びます) が含まれます。例えば、会社の収益に関するレポートを生成するために使用するデータ ウェアハウスの場合は、ファクト テーブル内に dollar_sales および dollar_cost という列を持つことになります (上の図を参照)。一般的に、ファクトは継続的に評価され、追加的なものです。"継続的に評価される" とは、ファクトが、測定のたびに別の値を持つ数値的な測定データであることを意味します。"追加的" とは、追加によってファクトを集約できることを意味します。

ファクト テーブルには、連結されたキー、つまり複合キーを形成する一連の列も含まれます。連結されたキーの各列は、ディメンション テーブルの主キーから得られた外部キーです。例えば、上の図では、ファクトを product_dimension テーブル内の特定の製品と関連付ける product_key という列がファクト テーブルに含まれています。

ファクト テーブル内の詳細レベルを粒度と呼びます。ファクト テーブル内のすべての行は、同じ詳細レベルで記録されている必要があります。上の図では、ファクト テーブル内の測定データがそれぞれの販売製品の日単位の売上合計 (ドル)、販売単位、費用 (ドル) になっています。粒度は日単位です。ファクト テーブル内の各レコードは、ある小売店での 1 日の特定の製品の売上合計を表しています。製品、店舗、または日の新たな組み合わせごとに、異なるレコードがファクト テーブル内に生成されます。

ファクト テーブルには、データ ソースから抽出されたデータが設定されます。データ ソースは、OLTP システムにすることもデータ ウェアハウスにすることもできます。Spectrum™ Technology Platform は、ソース データのスナップショットを定期的に取得し、通常は毎日、毎週、または毎月、同じ時間に、データをデータ ウェアハウスに移します。

スター スキーマは複数のファクト テーブルを持つことができます。ディメンション テーブルの共通のサブセットを共有する一連の測定データを分離したり、測定データを異なる粒度で追跡したりするには、複数のファクト テーブルを持つスキーマを使用します。

ディメンション テーブル

ディメンション テーブルは、ファクト テーブル内の情報を記述するデータを保存します。例えば、ある月と次の月で sales_total が異なっていた場合、その理由を知るにはディメンションを調べることになります。同じディメンション テーブルを別々のファクト テーブルで使用できます。

ディメンション テーブルは、属性と、そのディメンション テーブルをファクト テーブルに結合する単一パートの主キーを持ちます。属性は、ディメンション テーブル内の列です。単一パートの主キーにより、1 つのディメンション テーブルをすばやく参照できます。ディメンション テーブルの参照は、ファクト テーブルに対してクエリを実行する最適な方法を決定するのに役立つことがあります。

必要な日付データをレコードから容易には抽出できなないことがあるため、正確な時間ベースの計算では時間ディメンション テーブルが必要になります。例えば、以下のレコードが売上データベース内にあるとします。レコード間に時間的なギャップがあることに注意してください。例えば、2012 年 1 月 4 日のレコードがありません。

Date 製品
2012 年 1 月 3 日 赤いシャツ 10.00 ドル
2012 年 1 月 5 日 赤いシャツ 5.00 ドル
2012 年 1 月 7 日 赤いシャツ 15.00 ドル

これらのレコードに対するクエリを実行して 1 日あたりの平均売上を計算した場合、結果は 10.00 ドル (30 ドル / 3 レコード) になります。しかし、これは正しくありません。この 3 つのレコードは実際には 5 日間にわたって得られたものだからです。日ごとのレコードを持つ時間ディメンション テーブルがあれば、そのテーブルを上記のテーブルと結合して次のテーブルを得ることができます。

Date 製品
2012 年 1 月 3 日 赤いシャツ 10.00 ドル
2012 年 1 月 4 日    
2012 年 1 月 5 日 赤いシャツ 5.00 ドル
2012 年 1 月 6 日    
2012 年 1 月 7 日 赤いシャツ 15.00 ドル

これらのレコードを使用して 1 日あたりの平均売上を計算すると、6 ドル (30 ドル / 5 日) という正しい答えが得られます。

また、休日、週末、四半期など、任意の時間属性を計算で考慮することもできます。例えば、2012 年 1 月 6 日が休日で、1 営業日あたりの平均売上にのみ関心があるとした場合、答えは 7.50 ドルになります。

結合

結合は、スター スキーマ内のファクト テーブルとディメンション テーブルとの関連性を定義します。ディメンション テーブルの主キーは、ファクト テーブルの外部キーです。ファクト テーブルには、各ディメンション テーブルの主キーの値が含まれている必要があります。外部キーから主キーへの参照は、この 2 つのテーブル間で値を検証するためのメカニズムです。このタイプの結合関連性により、データ ウェアハウスの参照整合性が保証されます。有効なクエリ結果が確実に得られるようにするには、参照整合性を維持する必要があります。

ディメンション テーブル内の各レコードは、ファクト テーブル内の多数のレコードを記述でき、ディメンション テーブルからファクト テーブルへの結合のカーディナリティは 1 対多になります。

上の図では、product_key が product_dimension テーブルの主キーであり、sales_fact テーブルの外部キーです。この結合は、会社の製品とその売上との関連性を表しています。