PR

 RDBMSを使ってデータウエアハウス(DWH)を構築するとき、「サマリーテーブル」を作ることが多い。サマリーテーブルとは、既存のテーブルを結合したり集計したりした、分析用のテーブルである。派生テーブルや集約テーブル、データマートと呼ぶこともある。

 広く使われてきたサマリーテーブルだが、最近注目されているDWHアプライアンス上には作らない方がよい。DWHアプライアンスの多くは、明細データを読み取って集計することを想定して設計されている。こうなると、サマリーテーブルのメリットが薄れ、逆にデメリットの方が大きくなるのである。

サマリーテーブルの二つの問題

 サマリーテーブルを作ると、いったいどんな問題が起こるのか。大きく二つの問題が生じるだろう。

 一つは、メンテナンスの負担が増すことだ。サマリーテーブルの作成はユーザーではなく開発側が行う。分析内容の変更、ユーザーの追加といった改善要望に一つひとつ対応する必要がある。最近では、さまざまな角度で分析したいニーズがあるので、こうした要望に応えていると、メンテナンスコストの歯止めが利かなくなる。

 二つ目は、運用の負担が大きいことだ。サマリーテーブルの更新は、夜間バッチで行うケースが多い。このときバッチプログラムの不具合だけでなく、データの不整合が原因でバッチ処理が異常終了することが珍しくない。運用時にはこうした状況を常に監視する必要がある。サマリーテーブルが増えれば、運用担当者の負担は大きくなる一方だ。

サマリーテーブルなくても実用的な性能

 こうしたデメリットがあってもサマリーテーブルが使われてきたのは、パフォーマンスが高かったからである。しかし、高性能・高機能なDWHアプライアンスを使えば、サマリーテーブルを作らなくても実用的なパフォーマンスが得られる可能性が高い。サマリーテーブルを使わない形がこれからのDWHの姿といっていい(図1)。

図1●DWHアプライアンスではサマリーテーブルが不要になる
図1●DWHアプライアンスではサマリーテーブルが不要になる

 もっとも、サマリーテーブルがすべて“悪”というわけではない。サマリーテーブルを使い慣れたエンドユーザーにとっては、サマリーテーブルをそのまま使いたい場合もある。筆者も最近、あるDWHアプライアンスの導入プロジェクトで、数テーブルのサマリーテーブルをあえて残した。

 なお、DWHアプライアンスにはSMP(Symmetric Multi Processing)ベースの製品とMPP(Massive Parallel Processing)ベースの製品がある。性能面を重視するなら、超並列処理を実現できる後者のタイプをお勧めする。

 明細レベルの大量データを保持できるDWHアプライアンスは、サマリーテーブル主体の従来のDWHと比べて可能性が広がる。今まであきらめていたユーザーによる自由な検索操作が可能となる。データのレベルが粗かった点も改善される。これらはサマリーテーブルがないから実現可能になった。DWHアプライアンスにサマリーテーブルを作ってはいけない。


臼井 利公(うすい としまさ)
日本ヒューレット・パッカード HPソフトウェア・ソリューションズ統括本部 BIS事業本部 BIソリューション部 プロジェクトマネージャー
1989年、日本ヒューレット・パッカードに入社。製造業のデータベース関連プロジェクトに従事。2000年以降は、製造・流通業向けのデータウエアハウスシステムの導入を中心に、プロジェクトマネジメント業務を手掛ける。