データウェアハウス中心アプローチで問題解決しよう：システム部門Q＆A（14）（2/3 ページ）

[木暮 仁，＠IT]

データウェアハウスとデータマート

　ここでは、データウェアハウスは全社的なデータの保存庫であるセントラル・データウェアハウスを指し、データマートとは各利用部門のためのデータ保管庫であるとします。エンドユーザーは通常はデータマートにアクセスしますが、データマートは比較的小さなサーバですから、エンドユーザーのすべてのニーズに耐えるデータを常駐させることはできません。それで、必要に応じてデータウェアハウスからデータマートへデータを転送することになります。

　比ゆ的に、データマートを近所のコンビニエンスストア、データウェアハウスを卸売市場と理解するのが適切です。その対比を表に示しますが、データウェアハウスとデータマートとは、かなり性格が異なります。

　コンビニエンスストアでは、マグロがそのまま置いてあったら困ります。加工をしないで、あるいは簡単な調理ですぐに食べられるように加工した完成品になっていることが重要です。それに対して卸売市場では、刺身の盛り合わせや味付けをした完成品ではなく、どのようにでも加工できる原料・素材のままの方が便利です。また、プロが集まるのですから、操作の容易性はあまり問題になりません。むしろ、ここに来れば必要なものが必ずあり、それが適切に整理されていることが重要なのです。

1. データウェアハウスとデータマートの比較

	データウェアハウス	データマート
存在目的	データの整備保管	ユーザーの情報活用容易化
存在場所	集中（並列プロセッサ）	対象部門のサーバに分散
保管データ量	非常に大（逐次増大）	あまり大きくない
管理者	情報システム部門	ユーザーが望ましい
利用頻度	比較的少ない	頻繁
情報技術知識	ある程度の知識が前提	多様（初心者も多い）
重点観点	データが必ずあること	操作性が良いこと
データの内容	全社的体系的網羅性	対象部門用途に限定
データの目的性	汎用的・部品化	部門目的
データの構造	正規化・RDB	任意（多次元DB）

2. データウェアハウスでのデータの持ち方

　コンビニエンスストアであるデータマートでは、エンドユーザーが容易に情報を入手できることが重要です。それには、「個別帳票メニュー方式」や「直前ファイル」に加工したデータを提供するのが最適ですが、そうするためには情報システム部門の負荷が増大しますし、そもそもエンドユーザーのニーズを事前にキャッチして用意することはできません。そして、機能はある程度の制限はあるが、エンドユーザーにとって使いやすい多次元データベースの形式で持ち、OLAPツールで操作して、パソコンの表計算ソフトで編集するといった方法が適当です。

　それに対して卸売市場であるデータウェアハウスでは、データを個別の目的別に加工したものではなく、汎用的に利用されることが目的になります。すなわち、部品としてのデータとして考えるべきです。そして、その部品が統一された視点で整理されていることが重要です。それには、データは正規化をしてRDBの形式にするのが適しています。

〇オブジェクト指向との対比

　RDBでは複雑な構造のデータが取り扱えませんし、部品をデータとしてだけでなくメソッドも加えたオブジェクトを部品と考える方が適切ですから、本来ならば、RDBではなくオブジェクト指向データベースにした方が適切かもしれません。

　しかし現在では、オブジェクト指向の場合でもデータはRDBで実装していることが多いし、オブジェクトを全体的な体系で整理するのも難しいでしょう。複雑なデータ構造が必要なもの以外であれば、RDBにしておくのが適切だと思います。

〇大福帳の生データ

　データウェアハウスのデータは、基本的に売り上げなどのイベントが発生のたびに発生するデータをサマリせずに蓄えているディテールデータ（明細データ）です。一時、大福帳という言葉が広がり、そこでは「生データ」という表現をしていました。しかし、データウェアハウスでのディテールデータは正規化しているのに対して、大福帳の「生データ」は正規化を否定しているので、まったく異なった概念だといえます。

〇データウェアハウスでの派生ファイル

　データウェアハウスのデータは基本的には正規化したディテールデータですが、それではデータマートに転送するたびに負荷が掛かってしまいます。その観点から、正規化を緩めたファイルや適当な切り口で集計したファイルを持つこともよくあります。しかし、これはあくまでも便宜上派生させたファイルであると認識することが大切です。

3. データウェアハウスの必要性

　エンドユーザーが利用するのはデータマートであり、その基になるデータは、基幹業務系システムによりメインフレームに収集・蓄積されているのですから、必要に応じてメインフレームからデータマートに転送すればよいので、中間のデータウェアハウスは不要であるとも考えられます（下左図）。

左：データウェアハウスが無い場合。メインフレームはデータマートに適した形式に変換して転送しているためデータの変換が複雑だ
右：データウェアハウスがある場合。データウェアハウスはデータを正規化して持っているため、変換が容易で回数が少なくてすむ

　しかし、現実にはそうはいかないのです。エンドユーザーの要求は多様で変化します。データマートである部門サーバのディスク容量は比較的小さいので、すべてのデータをデータマートに常駐させられません。そのために、メインフレームから必要なデータをデータマートに適した形式に変換して転送することが多く発生します。

　基幹業務系システムは効率性や正確性など、基幹業務系システムに適したデータの持ち方をしています。それに対して、データマートは多様な切り口での検索に適したデータの持ち方をしています。ですから、基幹業務系システムのデータをデータマートに転送するときには、かなり複雑な変換処理が必要になります。双方のシステムをよく知っているベテランでないと、正しいデータがデータマートに転送されない危険があります。逆に、この業務にベテランを張り付けたのでは、情報システム部門が硬直化してしまいます。これがデータマートの運営を困難にしている大きな原因の1つなのです。

　それに対して、データウェアハウスではデータを正規化して持っています（右図）。これは初心者にも分かりやすいデータ体系です。それを仲立ちにすることにより、基幹業務系システムのデータを正規化データにすることも、正規化データからデータマートのデータに変換することも、比較的容易になりますし、M×Nの変換回数をM＋Nに減らすこともできます。

　基幹業務系システムからデータウェアハウスへの受け渡しは情報システム部門が行いますが、データウェアハウスからデータマートへの変換は、エンドユーザー側のキーパーソンに任せることができます。