ディメンションの整合性(準拠性)

ディメンションテーブルが横断検索が可能な条件を持っている場合、整合性があるディメンションといいます。（conformedをあえて、「整合性」と表しています）同一のディメンションを利用している場合は当然、整合性があることになりますが、それ以外においても整合性を持つことは可能です。ファクトテーブルと整合性のあるディメンションの関係は、将来の拡張実装で使用できるように整理しておく必要があります。

ディメンション整合性のタイプ

ここでは横断検索を可能にするか、妨げるかというディメンションテーブルの整合性について分類分けを行います。これまで見てきたようにディメンションテーブルの整合性にはいくつかのパターンがあります。今まで、「ディメンションの共有」「集約単位に整合性がある」という2つのパターンについて見てきました。ディメンションの非正規化(degenerate)もまた整合性のパターンです。「オーバーラッピングディメンション」と呼ばれる4つ目のパターンについては、あまり一般的ではありません。

ディメンションテーブルの共有

もっとも一般的なディメンションの整合性は二つのスターが同一のディメンションテーブルを利用することです。このディメンションの共有は「同一のテーブルを利用する」もしくは「二つ以上の同一構成のテーブルを利用する」というものがあります。2つ以上のテーブルを利用した実装の場合、ディメンションの共有は以下に従う必要があります。 * テーブルは同一の構成であること * テーブル内のデータ内容が同一であること

複数のディメンションがこれらの特徴を持っている場合、テーブルは整合性があるといえます。このタイプについてはすでに見てきています。 f:id:good-value:20171007155824j:plain

この受注と出荷の例において、「日」「商品」「顧客」ディメンションが共有されています。これまで見てきたように、これらのスタースキーマは同一のデータベースに存在する必要はなく、さらには別ベンダーのデータベースに存在していても問題はありません。ディメンションテーブルの構造とデータ内容が同一である限り受注と出荷の比較が可能です。

このディメンションテーブルが物理的に別のテーブルにある場合、ソースデータからのデータ取り込みについて、一つのETLプロセスで実施する必要があります。マスターとなるディメンションテーブルを最初に更新して、別の場所にあるディメンションにレプリケーションを行います。このレプリケーション（複製）手法をとることで、データの同期の手間を省き、分析の際に正確なデータであることを保証します。ただし、巨大なテーブルについては現実的ではありません。この場合、ETLプロセスは行の変更を判断し、更新キーを判断して各レプリケーションに反映を行う必要があります。

レプリケーションが別々に実施された場合、二つのディメンションのバージョンが同一であることを保証するのが難しくなります。それぞれのディメンションはソースデータから緩やかに変化するディメンション(Slowly Changing Dimensions) ルールに従い、同一の行データを持つ必要があります。データの比較を可能とするために同一のキー値を持つことも重要です。これまでに見てきたように、データのルールがバラバラの場合はデータの非互換につながります。

個別のデータロードプロセスは開発者にこれらの原則が必要であるという統制が難しくなり、片方に含む行がもう片方に含まれない状況や、同一のキー値をもたないということにつながります。それによりデータ分析における障害となります。不正確な複製データによりデータ分析が不正確なものとなります。データウェアハウスが不正確なデータを提供するとなると、誰も使わないものとなってしまいます。

次回は包含関係にあるディメンションテーブルについてです。（続く）