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

仮想的なビューの提供を優先的に検討する

　セントラルウェアハウスを構築するのがよいという考えに対し、消極的な意見もあります。「マスタデータの統合などできるわけがない」とか「企業レベルでデータを一箇所に集めるのは現実的とは思えない」という主張です。

　しかし、よくよくお話を伺ってみると、前者についてはマスタデータを新しい一つの体系に統合して最終的に業務系システムへフィードバックするという遠大な構想が前提になっていることがあります。私は、マスタデータの統合というのはデータウェアハウス内だけのことであって業務系システムへのフィードバックは想定していません。さらに同一実体に対する異なるコード体系はそのまま持ち込めばよく、串刺しにできる共通のキーが付加されればよいと考えています。また後者については、人事、会計、製造、販売、営業などすべてのデータを一箇所に集めるというイメージが浮かぶようで、たとえばWEBアクセスログ、データベース監査ログ、あるいは製造ラインの工程データといったものまでセントラルウェアハウスに入れることを想像されるようですが、このことに対する私の答えは勿論ノーです。私は、セントラルウェアハウに入れるデータというのは、複数の目的に使用されるデータだと考えています。

　たとえば、売上明細データが蓄積されれば、営業部、経理部、商品部、商品企画部、経営企画部などさまざまな部門の人が多種多様な目的で活用を始めます。これに対してデータベース監査ログは（そもそも基幹系業務システムで発生するトランザクションデータというわけでもありませんが）、監査部門の人がシステム監査という限定的な目的で参照するだけでしょうから、部門専用の独立したデータベースを作ればよいわけです。

　つまり、最初から複数の活用目的が明らかになっている、あるいはデータマート構築後にいろいろな活用の道が開けてきたという場合はセントラルウェアハウスを構築する。そして、分析、レポーティング、マイニング、トレーサビリティ、EUCなどいかなる用途にも応えられるようにデータは正規化する。さらに、各用途が特殊なスキーマを要求した場合、実体としてマートを作るという対応方法もありますが、初期段階では仮想的なビューの提供を優先的に検討する、というのが私の基本的な考え方です。

　昨年、ある小売業のお客様からデータウェアハウス案件の引合いがあり、要件のヒアリングに訪問した際、情報企画部の方から次のような説明がありました。

「このたび構築するデータベースは、情報系システムのあらゆるニーズに応える必要があるため、汎用的な構造にする。つまり、データベースは正規化してほしい。どのようなデータをどの程度蓄積するかは調査済みである。各部門におけるデータの照会要求にもとづくデータマートは別プロジェクトとして計画中であり、本件の範囲外とする」

　データウェアハウス案件といえばディメンジョナルモデルでOLAPが当たり前というという状況にあって、この説明には少々驚かされました。セントラルウェアハウスを指向されている企業は実際にあるのです。