データウェアハウスシステム設計概念

データウェアハウスアーキテクチャとはデータベース製品のアーキテクチャではなく、データウェアハウスシステムの設計概念を言います。つまりデータをどのように保存してどのように活用するのかという全体像のことになります。この話は多くの誤解とあまり本質的ではない論争（いわば宗教論争）があると言えます。用語が統一されていないので混乱させているというのもその理由の一つです。そのアーキテクチャの背景や目的が違うためですが、概念的なものの比較というのは一つ一つの細かい部分ではなく全体像を見る必要があります。

データウェアハウスアーキテクチャでよく出てくるのがエンタープライズデータウェアハウスアーキテクチャと呼ばれるもので、W.H.InmonとRalph Kimballの提唱する概念です。（それぞれ日本語ではInmmonはインモン、Kimballはキンボル/キンボールというように呼ばれています）この2人の概念について長い間論争なようなものがあります。ここで2つの議論を余分なものをそぎ通して全体視点で比較していきます。以下には「データマート」という言葉が出てきますが、利用システムが目的別に用意するデータのことで、データを利用しやすいように加工したものと考えてください。

インモン：コーポレートインフォメーションファクトリ

インモンは多くのデータウェアハウスアーキテクチャについて書籍を通じて普及をしています。コーポレートインフォメーションファクトリという概念になります。

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

ポイントは以下の通りです。

オペレーショナルシステムからETLでエンタープライズデータウェアハウス(EDWH)に格納する。
EDWHがデータハブとなり分析システムにデータを提供する。
EDWHのデータは最小粒度(Atomic)でありトランザクションそのもののデータを扱う。
EDWHでは第三正規形(3Normalized Formation)された状態でデータを格納する。
EDWHは直接クエリーによりデータ抽出を行うためにあるのではなく、利用システム（分析システム）はデータを加工した「データマート」を利用する。

キンボール：ディメンショナルデータウェアハウス

キンボールは2つの大きな業績があります。

スタースキーマという概念を普及させたこと。スタースキーマとはつまり多次元データモデル(dimensional design)を意味していることから、多次元データモデルの一人者ということになります。
多次元データモデルによるエンタプライズデータウェアハウスアーキテクチャを提唱したこと。「最小粒度のデータを統合させる」「分析用に多次元データモデルを利用する」というコンセプトですが、インモンのコーポレートインフォメーションファクトリと特徴が共通している部分は多くあります。キンボール自体がスタースキーマを重視していたため、スタースキーマの欠点についての議論がアーキテクチャそのものの欠点として非難されたり、さらにはスタースキーマ自体が非難されるという点もあったようです。

Because he is so closely associated with the star schema, he is often assigned blame for shortcomings associated with any implemantation that utilizes a star, regardless of its architecture. Other times, the star schema itself is assinged blame.

「インモン：コーポレートインフォメーションファクトリ」の図と見比べるとわかるのですが、基本的な概念は同一なものと言えます。

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

重要なポイントとしては以下が挙げられます。

多次元データモデルにてデータを保持していて、最小粒度のデータを（多次元データモデル）で保持しています。これはコーポレートインフォメーションファクトリでは第三正規形で保持されているので対照的です。
分析システムは多次元データモデルを直接参照し、さらに特定分析用のデータマートについてももデータウェアハウス内に作成されます。これはスタースキーマをバラバラに作成するのではなく、スタースキーマ間の関連性を持って作成するほうが望ましいからです。これについては整合性のある多次元データモデル(Coformed Dimension)という概念になりますがのちに解説していこうと思います。

個別データマート (Stand-Alone Data Marts)

個別データマートは今まで紹介してきた2つは違って、利用したい要件ごとにデータマートを用意する方法です。個別に利用したいように用意するので、成果は出しやすいのですがあくまでも「個別最適」なものですので、長期利用コストやシステム的な統制という点では非常に問題があります。

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

個別データマートが一つの時は問題はそのデータマートがデータウェアハウスの外にある（通常は別のデータベース）という構成になるという物理的な懸念点（保守性など）以外はないと言えるのですが、複数個のデータマートが構成された時に懸念点が顕著になります。運用コスト（採用技術、処理の冗長性）はわかりやすいのですが、それよりも大きな懸念点としては「データの互換性」についてあげられます。

データの統一管理からの逸脱（ERD定義の互換性の欠如）
別データマートとのデータ粒度の不整合

これらの理由によりデータマートは「閉じた世界の情報(islands of information)」になってしまい、データマートをまたいだデータ分析が出来ないという事態が発生することになります。個別データマートは短期に立ち上げるには非常に有用ですが、乱立すると非効率性が目立つようになるが通常です。採用するにあたっての将来の目途については事前に検討する必要があると言えます。

次回に続きます。