DB Stories

DBに関する過去、現在、未来の話題をプロフェッショナルの視点で紹介

スタースキーマとキューブ(7)

ここからはディメンションテーブルの履歴保持の方法について解説していきます。

緩やかに変化するディメンション(Slowly Changing Dimensions)

ディメンションテーブルのデータは業務システムにより生成されます。多次元データウェアハウスと個別データマートアーキテクチャにおいてデータは直接業務システムから取り込むことになります。コーポレートインフォメーションファクトリにおいては、エンタープライズデータウェアハウスを経由して多次元データマートと移動します。(参考:データウェアハウスアーキテクチャ) これらの例において一度スタースキーマににデータを取り込んだ後に業務システムで発生するデータの変化(変更)をどのように扱うかというのが問題になります。例えば、「顧客の誕生日を訂正した」「顧客の転居に伴う住所の変更」などがあげられます。

データの最下流であるスタースキーマにおいてはディメンションテーブルにおいてはサロゲートキーを利用しているため、Primary Keyが存在する業務システムと同様のデータ変更を行うことができません。業務システムにおいては業務に応じて変更履歴を保持したり、変更を上書きすることで対応します。同様にスタースキーマにおいてもデータ分析に即した方法でこの変更に対応することになります。

まずはじめに考慮しないといけないのは、データソース(業務システム)においてどのようにデータが変化するのかというのを把握することです。このデータの変化のことを緩やかに変化するディメンション(slowly changing dimensions)と呼びます。この用語は急激にデータが増えていくファクトテーブルと比較して、ディメンションテーブルは緩やかにデータが増加し変化してて行くという特性からきています。この変化については、データ分析の目的からデータ変更履歴を保持する価値がないものもあれば、変更履歴を保持することが重要となるものもあります。

以下の図は受注システムにおける顧客データについて3つの時系列を示しています。

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

  1. 登録時のデータ (2007年1月1日)
  2. 誕生日の訂正 (2007年1月31日)
  3. 引越しに伴う住所変更(2009年5月5日)

データソースにあたる業務システムにおいてはすべてデータは全て上書きされています。一方、分析業務を考えるとそれぞれの項目について検討する必要があります。受注データ分析業務を例に考えてみると、誕生日の変更については受注データ分析業務においては重要ではないので直接変更して問題ないと言えます。一方、住所変更については重要性があります。受注データについては東京都に住んでいた時のものと大阪府に転居した際のデータが存在しています。過去データについて都道府県別の受注状況を分析する際にどの都道府県にいるときのデータかというのが重要になります。

この2つのデータの変更がスタースキーマにおけるもっとも基本的なデータ変更パターンであるType1とType2を示しています。Type1はデータを上書きし、Type2はデータの履歴を保持します。さらに、それほどメジャーではありませんが、データの履歴は必要ないが変更前後のデータを保持するType3が存在します。

(次回、ディメンションのデータ変更について具体的な解説を行います)