DB Stories

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

データウェアハウスアーキテクチャ(2)

データウェアハウスアーキテクチャの特徴

前回、3つのデータウェアハウスアーキテクチャについて紹介しました。

  • インモンのコーポレートインフォメーションファクトリ
  • キンボールのディメンショナルデータウェアハウス(多次元データウェアハウス)
  • 個別データマート (Stand-Alone Data Marts)

www.dbstories.com

多くのデータウェアハウスのアーキテクチャはこの3つのアーキテクチャを利用しているはずです。(むしろ該当しない場合は、データウェアハウス利用に問題が出ているはずです)3つのアーキテクチャの特徴を表にしたものが以下になります。

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

インモンのコーポレートインフォメーションファクトリ、キンボールのディメンショナルデータウェアハウスはエンタープライズ利用を想定して、組織横断の業務分析が考慮されています。個々の分析ニーズごとに都度データの利用を実装しているわけではなく、効率よく扱えるように加味されているアーキテクチャとなっています。例えば、「顧客」「商品」といったデータは製造、販売、マーケティングという目的で利用されることになるため、データ粒度(たとえば、1日は0時から24時と統一するなど)、マスタデータといったデータの整合性が保たれていることになります。この全社視点(組織横断視点)でのデータの整合性という考え方がデータウェアハウスにおいて非常に重要な概念となります 一方、スタンドアローンデータマートは対照的に一つの部門の利用のみが想定されているため、全社利用という視点に欠けています。そのことが、組織横断のデータ利用を妨げることになるのは明白です。

組織横断という重要な要件から、そのため2つのエンタープライズデータウェアハウスアーキテクチャは「Atomic Data(サマリや加工する前の業務データベースから連携した最小粒度のデータと考えればよいです)を一つに統合したデータリポジトリを持つ」という共通の特徴を持ちます。このリポジトリ内には利用者個別の要件でのデータは含めないことになります。インモンモデルは「エンタープライズデータウェアハウス」、キンボール(ディメンショナルデータモデル)は「ディメンショナル(多次元)データウェアハウス」と呼ばれています。

これらの特徴をまとめたのが以下の表です。

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

全社レベル(Etnerprise Level)、目的別レベル(Subject Area Level)という2つの軸が存在していてそれぞれのポイントとして以下があります。

  • 全社レベル
  • Atomic Dataの統一したデータリポジトリの保持を持つか
  • 保持フォーマットは正規形か多次元データモデルか
  • このデータリポジトリに直接的なアクセスを可能とするか

  • 目的別レベル

  • 全社データとは別にデータマートを保持するか(ディメンショナルデータウェアハウスは物理的には保持しない)
  • データマート(個別用件向けに切り出したデータ)は多次元データモデルで保持する

インモンのコーポレートインフォメーションファクトリについては、目的別にデータマートとして物理的なテーブルを保持します。この点においては個別データマートアーキテクチャと同じと言えます。しかし、そのデータマート自体は全社データリポジトリであるエンタープライズデータウェアハウスより取得します。つまり、データマート自体は全社的なデータの整合性を持つことになります。そしてこのエンタープライズデータウェアハウスのデータモデルは第三正規形で保持します。エンタープライズデータウェアハウスに対する直接のデータアクセスが「禁止」というのは「第三正規形自体が分析業務に適していない」「データ取り込み(場合によってはデータの洗い替え)が実施されるためデータ利用面での独立性の確保」というところからきています。

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

キンボールの多次元データウェアハウスにおいて、データマートは物理的なデータを持つ必要はなく論理的な概念となります。具体的に言うと、データマートは多次元データウェアハウスのサブセットとなります。(どうしても実現できない時のみ物理的なデータマートが作成されることになります)つまり、こちらも全社的なデータ整合性を持っていることになります。多次元データウェアハウスは文字通り多次元データモデルでデータを保持します。

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

用語が統一されていないところが理解するうえで混乱の要因となるのですが、全社で集約したデータの集合(インモンならエンタープライズデータウェアハウス、キンボールなら多次元データウェアハウス)を持つというアーキテクチャ概念は同じで、そのデータ保持形態が異なるという点が一番のポイントです。

データウェアハウスアーキテクチャにおける誤解

インモン(コーポレートインフォメーションファクトリ)、キンボール(多次元データウェアハウス)の2つの考え方は対極的な文脈で語られることが多く「どちらが最適か」という点での考察について多く語られてきました。しかしながら、これまで見てきたように基本的な考え方は同じであり、どちらが良いという話ではないのが分かります。以下のような意見については全くの誤解であると言えます。

  • インモンはスタースキーマについて反対の立場をとる(anti-star schema)
  • キンボールは全社視点でのデータモデルの必要性がないと考えている
  • データマートは孤立した情報である(islands of information)
  • 多次元データモデルはサマリ(集約)データのためのものである
  • スタースキーマはストーブの煙突(stovepipe)である。(全体最適モデルではなく個別最適なサイロモデルであることを意味しています)

多次元データモデル

どのデータウェアハウスアーキテクチャにおいても、目的別データの保持は多次元データモデルを利用することになります。多次元データモデルはデータウェアハウスにおいて普遍的なデータモデルとも言えます。多次元データモデルの概念を理解する重要性はここにあります。

(つづく)