データウェアハウス構築の秘訣（1）

2つの考え方があるデータウェアハウス・システムの構成

　データウェアハウス・システムの構成には、2つの考え方があります。

　1つ目は、セントラルウェアハウスを構築し、そこに統合されたデータを活用するために目的別にデータマートを構築するという考え方です。この場合のデータマートは、セントラルウェアハウスのデータに依存することになるので、従属型データマートと呼ばれます。

　これに対し、セントラルウェアハウスの構築は必須ではなく、目的別にデータマートを構築すればよく、その集合体がデータウェアハウスであるという考え方があります。この場合のデータマートは、基幹系業務システムから直接データを抽出して構築される（セントラルウェアハウスに依存していない）ので、独立型データマートと呼ばれます。

　いずれの構成がよいのかと問われれば、私は迷わず前者と答えます。なぜなら、これまでの構築経験の中で後者を選択したことにより以下のような種々の問題に遭遇してきたからです。

• データマートを作るたびにデータソースの所在確認、抽出／転送／ロード（ETL）モジュールの開発など同じ手間がかかります。このため、新規ユーザニーズに即応できません。
• データマートは特定の分析要求に沿って開発されるため、当然ながら限定的な分析しかできません。このため、似て非なるデータマートが多数できてしまい、リソースを膨大に消費することになります。
• 企業レベルでのデータ統合が行われないため、クモの巣状のシステム形態という問題は解決されず、かえってETLのタコ足が加わりシステム間の依存関係が複雑になります。
• 切り口（視点）、データの詳細度（粒度）がデータマートごとに異なるため、いくつかのデータマートから作成されたレポートが整合しない場合があります。
• ETLツールやBIツールが統一されないため、メンテナンスに手間がかかります。また、基幹系業務システムの仕様変更やデータメンテ（修正）が発生した場合、データマート側のメンテナンスにも手間がかかります。

　このような経験を経て、私は、

　が適切な形態だと考えるようになりました。

　しかしこの式は、最初の一歩がセントラルウェアハウスの構築だという意味ではありません。むしろ、セントラルウェアハウスの構築自体をプロジェクトの目的にするのは好ましくないと考えています。その理由は、もしセントラルウェアハウスの構築をプロジェクトの目的とした場合、データ設計がトップダウン・アプローチにならざるを得ないからです。トップダウン・アプローチで設計するということは、企業内のエンティティを洗い出し、どのエンティティをセントラルウェアハウスに入れるのかを検討するところから始めるということで、これは非常に困難な作業です。かといって、各業務システムで使用されているデータをかき集め、業務担当者から業務内容およびデータ項目の意味をヒアリングして企業レベルのERDを作るというボトムアップ・アプローチを採ったとしても、大変な作業になるでしょう。

　したがって、単に企業レベルでデータを統合するためにセントラルウェアハウスを構築しようとするのではなく、特定のユーザニーズを解決する目的でデータマートを構築することろから始めるのがよいと思います。そのユーザ・ニーズを解決するためにデータを集める、新しいユーザニーズが出たら不足するデータを集めて追加するということを繰り返して段階的に成長させる、つまりセントラルウェアハウスを指向することが重要だと考えています。