DB Stories

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

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

緩やかに変化するディメンション(Slowly Changing Dimensions)のType1、Type2利用の考え方について解説を続けます。

Slowly Changing Dimensionのタイプ選択

スタースキーマ設計の重要な要素の一つにディメンションテーブル変更(穏やかに変化するディメンション)に対するルールの選択があります。ソースデータの変更に対しての正しいルールの選択は常に分析要件ありきで検討をおこなうことです。ETL開発者はそのルールに従ってデータローディングの実装を行うことになります。

Slowly Changing Dimensionタイプ別の実装設計

緩やかな変更はソースデータの変更をトリガーとして発生します。多くはディメンションテーブルの観点で語る場合が多くなります。Sue Johnsonの例において、ディメンションテーブルの誕生日列はType1属性、都道府県列はType2属性であると説明してきました。これらの決定は次の2つでまとめることができます。

  1. ディメンションテーブルの顧客ID(customer_id)に対して、誕生日の値が変化した場合、既存のディメンションテーブルのレコードを上書きする。
  2. ディメンションテーブルの顧客ID(customer_id)に対して、都道府県の値が変化した場合、ディメンションテーブルに新しい行を追加する。

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

Type1変更とType2変更の違いについて次のようにまとめることができます。

# アクション ファクトに対する効果
Type1 ディメンションの上書き 属性の再定義
Type2 ディメンションテーブルへの追加(insert) 履歴の保存

多くの場面において、Type2の選択が最適となります。これは既存のファクトを再定義する訳でなく、ディメンションテーブルの履歴保持能力を喪失させることもないからです。不幸にも設計初心者(novice design tems)においてはそれとは反対の方法であるType1を選択してしまう場合があります。このことは決まって「オリジナルのソースデータを再読み込みすることなしに、データ訂正ができない」という問題を引き起こします。Type1変更は後で述べるさらなる複雑さについてももたらすこともあります。(Type1変更の混乱:Complications)

どちらのType変更を選択をしうる場面が存在しています。多くの業務システムは重要な属性項目の変更にいてのログを保持しています。これらのシステムは「変更の理由」を記録している場合、スタースキーマでどのように対応すべきかというのが分かります。たとえば、顧客の「結婚(未婚/既婚)」属性は業務システムで「エラー訂正」と記録されていればType1変更となり、実際の変更(結婚、離婚)が発生していると記録されていればType2として扱うことになります。

ここで紹介したType1,type2変更に加えて、ソースデータにおいて別の変更内容が発生する場合もあります。Type3変更、ハイブリッド、タイムスタンプというのがあり得ます。これらについてはさほど登場する場面が多くないため、後でまとめて紹介することにします。

Type1変更の混乱:Complications

Type1変更はファクトの履歴を持たないということに加えて、別の混乱を引き起こすこともあります。あるディメンションの項目をType1変更とし、さらにナチュラルキーとは関連しない項目だとした場合、その項目の変更について慎重に評価する必要があります。例えば、次の属性を持つ商品テーブルを仮定します。

  • 商品コード(brand code:Type2)
  • 商品名(brand name:Type1)

ナチュラルキーである商品コードに対応した商品名を変更した場合、商品名は変更(update)することになります。一方、別商品として扱う商品名の変更は新規レコードを追加(insert)します。

さらに、Type1変更項目はスタースキーマをもとに作成される「集約テーブル」や「キューブ」を扱う際に問題が発生します。これについては後程「集約」を扱う際に解説します。

Slowly Changing Dimensionの実装

先ほどの図のように、Type1,Type2変更の双方が含まれるディメンションテーブルの場合、ETL開発者はさまざまな状況を考慮に入れる必要があります。例えば、Type1変更はディメンションテーブルの複数行を更新する可能性があるという点です。もし、Sue Johnsonの誕生日(Type1)の変更が転居後に発生したとしたら、転居(住所はType2)の際に1行追加されているため、Type1変更は複数行に行う必要があります。そうしないと、Sueの誕生日が複数バージョン存在することになってしまいます。ETL開発者はType1とType2変更が同時に発生する場合も考慮に入れる必要があります。例えば、Sueの転居(Type2)と誕生日の変更(Type1)が同日に発生した場合です。ソースデータとして連携される1行にType1とType2の2つの事象が含まれることになります。

Slow Changeの発生をETL開発者が考慮に入れることは非常に難しいこととなります。Slow Change要件は複雑さとパフォーマンスという点でロードプロセスに大きな影響を与えます。ETL開発者は変更をどのように取り込むかと行く課題に直面することになります。この課題については後程ETLの解説を行う部分で取り上げます。

(次回はCubeについてです)