データウェアハウスにおけるデータの持ち方に関する考察

はじめに

　企業が経営環境の激変に対応するためには、ユーザ（情報システム部門以外のコンピュータ利用者）が、コンピュータに蓄積されているデータを多様な切り口で検索加工して、迅速に意思決定をすることが重要である。また、顧客満足を達成するためには、大量の売上データから個人としての顧客（個客）の購買行動を把握して、販売政策に活かすことが重要である。
　これらの重要性は従来から認識されていたが、コンピュータのハードウェアやソフトウェアの限界により、十分に実現することができなかった。それが、最近のハードウェアのコストパフォーマンスの飛躍的向上、ソフトウェア技術の発展、通信環境の整備などにより、このような利用が実務的に可能になってきた。それにより、最近、データウェアハウス（Data Warehouse）の概念が注目されている。データウェアハウスとは、ユーザがデータを多様な角度で分析するためのデータの持ち方やツールの総称である。
　このように、データウェアハウスは経営的観点からも重要な概念であり、その構築は今日的な課題である。しかし、この構築にはかなりの投資が必要でありリスクを伴う。効果的な構築をし運営をするためには、多角的な観点から検討をする必要がある。
　ところが、データウェアハウスの概念は多様である。広義のデータウェアハウスは、全社的データの保管庫としての狭義のデータウェアハウスと、ユーザが実際に利用する部門的サーバに設置されるデータマートに区分されるが、かならずしもその区分は明確になっていない。ときには、この二つが混同して論じられる場合もある。
　本稿では、まずデータウェアハウスとデータマートとは違うものであると認識したほうが適切なことを述べる。そしてデータウェアハウスでは、データを正規化してＲＤＢ(Relational Database ）で持つことが重要だと指摘して、これをＯＬＤＰ（Online Data Parts ）データと命名する。
　分析のためのデータは、ＯＬＡＰ（Online Analytical Processing）データと呼ばれ、基幹系システムでのデータであるＯＬＴＰ（Online Transaction Processing ）データと比較がなされることが多い。しかし本稿では、その二つでの比較よりも、ＯＬＤＰを加えた三者の比較のほうがより適切であることを示す。

１．データウェアハウスの概要

　ここでは、データウェアハウスの概念を、とくに利用する観点でのデータの持ち方を中心に概観する。

１．１　データウェアハウスの定義

　Inmon,W.H.(1992) は、データウェアハウスを次のように定義した[1] 。
　「データウェアハウスとは、
　・サブジェクト指向（Subject-oriented）^１）
　・統合化（Integrated）
　・恒常的（Non-volatile )^２）
　・時系列（Time-variant）
の特性を持つ、マネジメントの意思決定を支援するデータの集合である」。
　現在では、これがデータウェアハウスの定義として、一般的に受け入れられている。そして、データウェアハウスの持つべきデータの特徴として、次のＯＬＡＰとＶＬＤＢが重視されている。

１．２　ＯＬＡＰ

　コンピュータの専門家ではないユーザが、コンピュータに蓄積されているデータを多様な角度から分析するには、ユーザ部門に設置されたＣＳＳ（Cliant-Server System）環境において、オンラインで操作性のよいツールを用いて分析できることが必要である。それには、そのような用途に適した構造でデータを持つことが必要である。
　Codd,E.F.(1993) は、このような用途をＯＬＡＰ（Online Analytical Processing）と命名し、ＯＬＡＰデータが持つべき条件として、表１の「１２のルール」^３）を提唱した[2] 。

　　　　表１　Coddの１２のルール

１　多次元的概念ビュー（Multidimensional Conceptual View）
２　透過性（Transparency）
３　アクセス可能性（Accessibility）
４　一貫したレポート性能（Consistant Reporting Performance）
５　クライアントザーバ・アーキテクチャ（Cliant/Server Architecture）
６　次元の一般性(Generic Dimensionality)
７　動的スパース行列処理（Dynamic Sparse Matrix Handling）
８　マルチユーザ・サポート（Multiuser Support）
９　制約のない次元間の演算処理（Unrestricted Cross-Dimensional Operations）
10　直感的データ操作（Intuitive Data Manipulation）
11　柔軟性のあるレポート（Flexible Reporting）
12　制限のない次元や集約レベル（Unlimited Dimensions and Aggregation Levels）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　（E.F.Codd, 1993）

１．３　ＶＬＤＢ

　個客の購買行動を把握してマーケティングに活用するには、ＰＯＳやカードなどのシステムで収集したディテールデータ^５）を長期の時系列に持ち、それを分析する必要がある。そのようなデータは非常に大きなサイズになる。場合によっては数百ＧＢあるいは数ＴＢ（テラバイト＝１０^９バイト）になる例もある。このような大規模サイズのデータベースをＶＬＤＢ（Very Large Database ）という。
　ＶＬＤＢを多様な切り口で分析して、販売政策での有用な情報を発見したり、仮説を検証することをデータマイニング（Data Mining ）というが、ＶＬＤＢを保管し、高速にデータマイニングを行うには、大容量のディスクと高速なプロセサが必要になる。そのために、超並列プロセサの利用が期待されている。

２．　問題認識

　データウェアハウスの概念は上記のようなものであるが、それを実際に構築し運営するには、いくつかの問題が生じる。そのうち、データに関する問題を列挙する。

２．１　データウェアハウスとデータマートで持つべきデータ

　データウェアハウスを構築するには、一方では操作性を重視したＯＬＡＰがあり、それにはユーザ部門に配置したサーバ（これをデータマートという）が利用される。他方ではＶＬＤＢの処理がある。当然ながら、データマートのディスク容量は小さいので、それにＶＬＤＢを持たせることはできない。
　また、ＶＬＤＢは、単にデータマイニングのためだけではなく、全社的なデータベースとして位置づけられることが多い。これを（狭義の）データウェアハウスという。すなわち、データウェアハウスには、各データマートへ送るデータの元になるデータを保管する機能がある。ＶＬＤＢの利用には、超並列プロセサが適しているが、１台の超並列プロセサで全社からのＯＬＡＰ利用を処理するのでは、応答時間が遅くなるとか、各部門に特化した利用がしにくいなどの問題がある。
　このように考えると、単にデータウェアハウスを全社用、データマートを部門用と規定しただけでは、適切な運用はできない。この両者のそれぞれに、どのような機能を持たせるか、そのためにはどのようなデータの持ち方をすればよいかが問題になる。

２．２　サブジェクト指向への対処

　データマートが持つことができるデータ量は比較的小さいので、すべてのユーザニーズに応えることはできない。そのために、必要に応じてデータウェアハウスからデータマートにデータを転送する必要がある。ところが、ユーザニーズは頻繁に変化するので、多くのデータマートがあるときには、その転送頻度はかなり多くなる。
　また、データマートでは操作性が重要であるから、データをサブジェクト指向（すなわち目的別）に持つ必要がある。そのため、データマートへの転送にあたっては、ユーザの目的に合致したようにデータを編集する必要がある。多い要求頻度に対処するには、その編集作業が容易であることが重要になる。さもないと、多くのユーザ要求に対して、そのつど変換プログラムを個別に作成することになり、要求から転送までに長時間かかってしまう。そればかりでなく、情報システム部門はその作業のために硬直化する危険もある。

２．３　統合化への対処

　データマートに転送する元のデータは、基幹系システムで収集蓄積したものである。ところが、基幹系システムでは、正確性や効率性が重要であるから、そのデータ構造は、ＯＬＡＰに適した構造にはなっていない。たとえば、販売システムの得意先と購買システムの仕入先では、相手企業という観点では同じであっても、それぞれ登録してある企業が違っていたり、コード体系が異なっていることすらある。これでは、仕入先への自社商品の売上状況を知りたいというような、統合的な分析をするには不都合である。
　このような不都合を抜本的に解決するには、基幹系システムそのものを、統合化した観点から再構築するのが望ましい。ところが、現実には統合化されないままに残っているシステムは多く、それを全面的に改訂するには多大のコストや時間がかかる。全面改訂を待っていたのでは、なかなかデータウェアハウスは構築できない。

３．ＯＬＤＰの提案

　本稿では、上記のような問題認識にたって、それを解決する方法を検討した。データウェアハウスとデータマートを区別する必要があり、データマートではＯＬＡＰデータの形式で持つが、データウェアハウスではデータを汎用的なデータ部品として持つことが重要であるとした。そして、データウェアハウスでの部品としてのデータの持ち方をＯＬＤＰと名付けた。

３．１　データウェアハウスとデータマートの違い

　機器構成を、図１のように全社的データの保管庫と、部門別データの保管庫の２段構成として考える。これらを総称してデータウェアハウスということもあるし、全社的データ保管庫のことをデータウェアハウスということもある^６）。本稿でも、ここまでは両者を総称してデータウェアハウスといってきた。 　しかし、データの持ち方や運営の面を考察するには、データウェアハウスとデータマートは違うものであると認識するほうが適切である。それで本章では、データウェアハウスとデータマートを明確に区分することにする。

　基幹系システム　　　　　全社的データ　　　　部門別データ

　　　　　　　　　　　　　　　　　　　　　　┌──────┐　　　クライアント
　┌───────┐　　┌──────┐　　│データマート│
　│　メイン　　　｜　　│データ　　　│　　└──────┘　　　クライアント
　│　フレーム　　│　　│ウェアハウス│　　┌──────┐
　└───────┘　　└──────┘　　│データマート│　　　クライアント
　　　　　　　　　　　　　　　　　　　　　　└──────┘
　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　│←　（広義の）データウェアハウス　→│
　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　│

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

（１）両者の目的の違い

　データマートは、多くのユーザが利用するので、あまりコンピュータの知識がなくても、簡単な操作で迅速に情報が得られるようにすることが重要である。それには、ユーザ部門に設置したＣＳＳのサーバをデータマートにして、ユーザの目的別に加工したＯＬＡＰデータを持つことが望ましい。多次元データベースはデータマートに適したデータの持ち方であるが、これが唯一のものではない。どのようなデータの持ち方でも、どのようなツールを使うのでも、利用する者に適していればよいといえる。
　しかし、サーバのディスク容量は比較的小さいので、すべてのユーザニーズを満足するデータを保管することはできない。それで、全社的なデータ保管庫としてデータウェアハウスを設置しておき、そこから必要に応じて、データマートにデータ転送することになる。
　比喩的にいえば、データマートを製品倉庫とすれば、データウェアハウスは部品倉庫であり、データマートを近所のコンビニエンスストアとすれば、データウェアハウスは卸売市場なのである。
　データウェアハウスのデータは、多様なニーズに応えることが重要であるから、データは個別の目的別に加工したものではなく、汎用的に利用されることを目的にすべきである。データウェアハウスは、部品の倉庫である。部品が中途半端な半製品ばかりになっていると、それに合致した製品を作るのには便利であっても、そうでない製品を作るのには使いにくいものになる。
　このように、データウェアハウスとデータマートとは、かなり性格が異なるものである。その対比を表２に示す。

　　　　　　　表２　データウェアハウスとデータマートの比較

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

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

（２）データマイニング的利用での検討

　ユーザがデータウェアハウスを直接アクセスするのは、標準的ではない処理であるから、それを必要とするユーザは比較的少数の者に限定できよう。また、データマイニング的な目的でデータウェアハウスを利用するユーザは、企画部門や販売部門などのスタッフであるから、ある程度の情報処理技術レベルを要求してもよいであろう。
　このような利用は、利用頻度が比較的少ないので、ユーザが利用するのを情報システム部門が支援することもできる。このように、データウェアハウスを直接に利用するときには、「誰もが容易に」という要請は、ある程度緩和してよい。
　さらに、データマイニングのような利用では、ある質問に対する結果をみて、次の質問をするようなプロセスになる。質問するときになって、利用すべきデータが決まるので、データウェアハウスのデータ体系を構築する時点で、利用されるデータ体系を確定することは困難である。この観点からも、データウェアハウスのデータは、汎用的なデータ部品として利用できるように、ＲＤＢにしておくほうが便利である。

３．２　基幹系システムでのデータの特徴

　データマートで用いるデータは、基幹系システムで収集蓄積したものが大部分である。それならば、メインフレームからデータマートに直接転送すればよいので、データウェアハウスは不要だとも考えられる。しかし、基幹系システムでのＯＬＴＰデータはＯＬＡＰデータとはかなりかけ離れているので、基幹系システムのデータから直接にデータマートのデータに編集加工するには、複雑なプログラムを作る必要がある。

（１）ＯＬＴＰとＯＬＤＰとの比較

　ＯＬＡＰデータの特徴は、基幹系システムでのＯＬＴＰデータと比較して説明されることが多い。

　　　　　　表３　ＯＬＴＰとＯＬＡＰの比較

　　　　　　　　ＯＬＴＰ　　　　　　　ＯＬＡＰ

　　システム　　基幹業務系システム　　情報検索系システム
　　処理　　　　データの正確性　　　　データの多様な加工
　　目的　　　　定例的な業務処理　　　意思決定の支援
　　内容　　　　現期間中のデータ　　　時系列的データ
　　更新　　　　非常に多い　　　　　　原則として更新しない

　これだけの違いならば、ＯＬＴＰからＯＬＡＰに変換するのも大したことではないように思われる。しかし、現実の基幹系システムでのデータは、ここでのＯＬＴＰとは必ずしも一致しない。
　基幹系システムの目的は、定例的定型的な業務を正確に効率的に行うことにあり、データもその目的に合わせて作られている。しかも、販売システムや生産システムというように、縦割り的な業務を対象になっている。最近では基幹系システム構築でデータ中心アプローチが普及して、目的別全社的データベースとしての観点が重視されてきたが、未だ全面的にそうなっているとはいえない。しかも、極度にデータの汎用性を図ると、個々のシステムでの特徴を失うことになり、基幹系システムの本来の目的である効率性が維持できなくなる。
　すなわち、ＯＬＴＰデータもＯＬＡＰデータと同様に目的別データなのである。しかし、その目的が、ＯＬＴＰでは正確性や効率性にあり、ＯＬＡＰでは操作性や有効性にあるので、データの持ち方はかなり異なる。そのために、ＯＬＴＰからＯＬＡＰに直接に変換するのには、かなり複雑な処理が必要になる。いくつかの具体例を次に列挙する。

（２）トランザクションファイルのデータの違い

　基幹系システムでは、事後の検証を容易にするための履歴データが必要である。たとえばあるデータを入力をした後で、入力誤りや事後訂正が発生して訂正するようなとき（いわゆる赤伝処理）には、前のデータを消去するのではなく、抹消のフラグをたてておくだけにするのが通常である。ところがそのようなデータは、分析のような利用をするときには、修正発生原因の追求など特殊な目的を除けば、ほとんど役に立たないし、処理を複雑にするだけである。
　また、５月の納入商品が６月に返品になったとする。基幹系システムでは、月次で締めるのが通常であるから、売上データは５月のファイル、返品データを６月のファイルに別個に持つのが一般的である。ところが売上分析などの利用では、５月の売上から返品分を差し引いておくほうが実状を表す場合が多い。それに、基幹系システムのデータをそのまま時系列に蓄積したデータを用いて分析するのでは、返品の数量はマイナスになっているのか、返品というコードがあり数量はプラスになっているのかなどが重要になる。このようなあまり本質的ではない事項までユーザが熟知しないと使えないようなデータ体系は、分析用データとしては不適切である。

（３）マスタファイルの必要項目の違い

　マスタファイルに持つべき項目が、基幹系システムとデータウェアハウスとでは大きく異なる。基幹系システムでのクレジットカード処理を例にすれば、顧客マスタの項目として銀行口座や引落日などは必須項目であり、この種の項目が多く入っているが、これらの項目はデータマイニングなどの利用ではあまり使われない。また、プライバシやセキュリティの観点からも、なんらかの変換処理が必要になる。

　市区町村マスタを例にすれば、基幹系システムでは請求書などの宛先印刷に使うだけだとすれば、コードと漢字名称があれば十分であり、効率の観点から必要以外の項目は持たないほうがよい。ところが石油業でのデータウェアハウスでは、人口、自動車台数、ガソリンスタンド数などの項目が市場分析には必須である。

３．３　ＯＬＤＰの提案

　ここではデータウェアハウスでのデータの持ち方をＯＬＤＰ（Online Data Parts）７）と命名する。これは、情報入手のためにデータを部品として持つためのデータ体系の概念であり、いわゆる情報系公開ファイルに要請されていたデータ体系であるともいえる。

（１）ＯＬＤＰの位置づけ

　ＯＬＡＰデータは、一般的にＯＬＴＰデータから得られるものであるが、ＯＬＴＰは個別の基幹系システムの正確性や効率性を目的としたものであり、ＯＬＡＰは個別のユーザの利用での操作性や有効性を目的としているので、その間には大きな違いがある。その間を埋めるために、ＯＬＴＰデータをいったん汎用的なデータ部品に変換しておくのがよい。それがＯＬＤＰデータである。
　ＯＬＡＰの特徴をＯＬＴＰとの比較で説明することが多いことは前述した。しかしそれでは、なぜ全社的データ保管庫としてのデータウェアハウスが必要なのかを説明できない。表４のようにＯＬＴＰとＯＬＡＰの間にＯＬＤＰを置いて、その三つの関係でとらえるほうが適切である。

　　　　　　　　　表４　ＯＬＴＰ・ＯＬＤＰ・ＯＬＡＰの比較
　　　　　┌─────────┬─────────┬────────┐
　　　　　│　　ＯＬＴＰ　　　│　ＯＬＤＰ　　　　│　ＯＬＡＰ      │
　　　　　├─────────┼─────────┼────────┤ 
　　　　　│基幹系システム　　│データウェアハウス│データマート    │                 
　　　　　│目的別（業務別）　│汎用的（部品的）　│目的別（部門別）│
　　　　　│正確性・効率性　　│汎用性・網羅性　　│操作性・有効性  │
　　　　　│現実には未統合　　│統合化　　　　　　│統合から派生    │
　　　　　│更新あり　　　　　│更新なし　　　　　│原則的更新なし  │
　　　　　│ディテールデータ　│部分的にサマリも　│サマリが多い    │
　　　　　│現在状況　　　　　│時系列　　　　　　│時系列          │
　　　　　│正規化不十分　　　│正規化が重要　　　│非正規化も必要  │
　　　　　│定例的数値データ　│多様なデータ　　　│　　　　　　　　│
　　　　　└─────────┴─────────┴────────┘

（２）正規化の要請

　データを汎用的な部品にするには、データの構造を体系化して、わかりやすくすることが重要である。それには、現在では正規化してＲＤＢの形式で持つのが適切である。
　ユーザにとって、ジョイン（複数のファイルの結合）の概念は難しすぎるという意見がある。しかしこれは、データマートの操作でのことである。データウェアハウスを利用するときには、操作を容易にすることよりも、どの項目がどのファイルにあるか、その項目はどのような内容なのかなどを、ユーザが容易に知ることができることのほうが重要なのである。それには、ユーザにわかりやすい辞書（メタデータ）を設定することが有用である。汎用目的のデータを対象にこのような辞書を設定するには、データが正規化されている必要がある。
　将来は、オブジェクト指向データベースの利用も期待されるが、現在ではＶＬＤＢのような大規模データでの適用は効率的に困難であるし、適切なオブジェクトの持ち方についてのノウハウがまだ不十分であると思われる。

（３）データの内容

　ＯＬＤＰデータは、ＯＬＡＰデータのもとになるものであるから、時系列データを持つ必要がある。ＯＬＤＰデータはＯＬＴＰデータから作成するが、その内容は分析に必要な観点で取捨する必要があり、ＯＬＴＰでの内容とは異なる場合がある。
　また、データ部品として活用するには、基本的にはディテールデータで持つべきであるが、効率的な観点からサマリ化したデータも持つ必要がある。それに対してデータマートでのＯＬＡＰデータは、ディスク容量や処理時間の制約から、あまり大きなデータにはできないので、近時点のデータを別にすれば、サマリ化したデータを中心にすべきである。

４．ＯＬＤＰの意義

　このＯＬＤＰの考え方を採用することにより、前述の問題認識で取り上げた事項が、比較的解決しやすいことを述べる。それとともに、この考え方は基幹系システムの再構築にもよい影響を与えることを示す。

４．１　データマートとの関連

（１）データマートの負荷低減

　データマートはいくつもの部門に設置されるので、データマートの個数は多い。データマートに大規模なデータを置くには、そのハードウェアであるサーバの機能を強化する必要がある。また、大量のデータを転送するには、通信回線を高速化しなければならない。サーバや通信回線の価格性能比は急速に向上してはいるが、それでもその費用はかなり高いものになる。
　データマートを軽くするには、全社的データベースとしてＯＬＤＰを構築しておき、必要に応じてそこからデータマートへデータを転送するようにするのがよい。そのときに、ある程度の加工をデータウェアハウス側で行えば、転送量を少なくすることができる。

（２）個別対処による負荷増大の危険

　データマートにデータを転送するには、その加工が容易でなければならない。その加工に費用がかかるのでは、データマートを軽くすることがかえって不利になる。前述のように、ＯＬＴＰデータとＯＬＡＰデータには大きな差があるので、その変換ロジックは複雑になる。市販の変換ツールもあるが、それが有効なのは、基幹系システムがかなり統合化されているときであり、そうでないときは複雑な変換のために、個別に変換プログラムが必要になることが多い。
　データウェアハウスの構築はコストがかかるし、その効果はユーザの活用にかかっている。データマートに置くべきデータも試行錯誤で整備していく必要がある。このようにリスクが大きいものであるから、データウェアハウスの導入実施では、当初は小規模に始めて、逐次拡大するのがよいというのが定説である。
　小規模に開始した当初では、変換のためにそのつどプログラムを作っていてもよいかもしれない。ところが、データマートに必要なデータは、ユーザが増大するに従い多様になる。データマート利用が活発になるに伴い、変換作業も頻繁になる。そのときも個別に変換プログラムを作成していたのでは、ユーザニーズに即応できなくなるし、情報システム部門が多忙になってしまう[4] 。
　ＯＬＤＰが整備できていれば、汎用目的のデータ部品からの変換であるから、そのロジックは比較的簡単である。市販ツールが有効に使える割合が増大するし、技術力のあるユーザなら、自分で必要なデータを取り出すこともできる。これは、情報システム部門の負荷増大が回避できるだけでなく、ユーザが自分のニーズに合致したデータを迅速に得ることにも有効である。すなわち、データウェアハウス利用の比較的早期の段階でＯＬＤＰを構築することが効果的である。

４．２　基幹系システムとの関連

（１）基幹系システム再構築の動向

　最近は、従来の基幹系システムの再構築を実施あるいは検討している企業が多い。従来のメインフレームを中心としたレガシィシステムを、ＣＳＳ環境を中心としたダウンサイジングあるいはライトサイジングに移行しようとしている。
　その理由には、コストダウンも大きな要素であるが、それだけでなく、エンドユーザコンピューティング（End-user Computing :以下ＥＵＣという）の推進を意図していることが多い。ＥＵＣはＯＬＡＰ以外の形態も含むが、ＯＬＡＰはＥＵＣの発展形態の一つだといえる。
　再構築のもう一つの理由は、従来の基幹系システムが販売システムとか経理システムというような業務縦割りのシステムであったのを、全社的な観点から統合化したシステムに改訂したいからである。そのために、データ中心アプローチなどのシステム開発方法論が広く採用されるようになってきた。
　本来は、まず基幹系システムを統合化して、それの延長として、ＯＬＡＰを構築するのが正統的なアプローチではある。Inmon,W.H. も、データウェアハウス構築には、基幹系システムの統合化が重要であるとして、その統合化したデータをＯＤＳ（Operational Data Store）と名付け、それの重要性とデータウェアハウスとの関係を述べている[5] 。

（２）再構築に先行させる効果

　基幹系システムの全面的改訂は望ましいことではあるが、非常に費用と時間がかかる。収支状況が悪いときには、効果がわかってはいても実施できないこともある。また、基幹系システムは企業の活動に密着しているので、常に維持改良している必要がある。維持改良のために情報システム部門が硬直化しており、抜本的改訂すべきだとは認識していても、実施できないでいることもある。このような理由により、基幹系システムの整備を待っていたのでは、データウェアハウスの構築はいつになってもできないことにもなりかねない。
　そこで、基幹系システムの再構築をする以前に、情報系のデータベースとしてＯＬＤＰを構築することが考えられる。これは、現行の基幹系システムから派生して作ればよいので、再構築と比較すれば、かなり小規模な時間と労力でできる。
　ＯＬＤＰの構築を先行することにより、それを基幹系システムの再構築への指針にすることもできる。前述のように、基幹系システム再構築の大きな目的がＥＵＣの推進や統合化にあるのだから、ＯＬＤＰはその目標であるともいえる。ＯＬＤＰ構築には当然ユーザの参画が得られる。ここでユーザの意向を反映して項目名称やコード体系の統一をしておけば、基幹系システム再構築での作業がかなり低減できる。
　しかも、ＯＬＤＰは基幹系システムと比較すれば、継続性や保全性をあまり重視しないでよい。ある程度の試行錯誤が許される。すなわち、ＯＬＤＰの構築は、基幹系システム再構築にも有益なのである。

４．３　ユーザ部門による運営

　ＯＬＤＰがなく、直接にＯＬＴＰデータからＯＬＡＰデータに変換するのであれば、その変換作業は情報システム部門が行う必要がある。それは、単にロジックが複雑なためだけではない。ＯＬＴＰは実際に運用しているデータであり、それをユーザが直接アクセスするのでは、データの保全性やセキュリティにも考慮する必要があるからである。
　それに対してＯＬＤＰでのデータは、ある特定のデータは別にして、基本的には公開を前提としたものであり、非更新データである。単純な管理をすれば、ユーザが任意にアクセスしても、保全性やセキュリティを考慮する必要が少なくできる。
　ＯＬＤＰをユーザに公開すると、もしユーザに技術的知識があるならば、ＯＬＡＰデータの管理もユーザに任せることができるようになる。これは、ＥＵＣやＣＳＳの運営管理に有効な体制である。
　それには、ＯＬＤＰデータの体系や内容を示したユーザ辞書が必要になる。これをメタデータというが、メタデータ機能が最も整備されているのはＲＤＢであり、それを効果的に運用するにはデータが正規化されている必要がある。この観点からもＯＬＤＰは正規化しＲＤＢで持つのが適切である。

おわりに

　現在の経営にとって、戦略的な観点でも日常的な観点でも、情報を利活用することが重要であることはいうまでもない。その一つのアプローチがデータウェアハウスの構築である。ところが、これはリスクが大きい。有効に利用すれば優れた武器になるが、運用を誤ると大きな出費になってしまう。それを誤らないためにも、多面からの検討が必要になる。 　本稿では、その検討の一つとして、データウェアハウスとデータマートとは区別して認識する必要があることと、データウェアハウスのデータの持ち方として、汎用的なデータ部品であることを重視したＯＬＤＰが有効であることを示した。
　データウェアハウスは、単にデータウェアハウスとしてとらえるのではなく、情報システム全体の一環として把握すべきものである。そして、ＯＬＤＰの考え方は、データウェアハウスだけではなく、ＥＵＣの推進やや基幹系システムの再構築にも役立つ考え方である。
　なお、ここではデータマートについてはあまりふれなかったが、データマートも単にＯＬＡＰだけではなく、ＣＳＳでのサーバとして、基幹系システムやワークフローシステムなどでの中核的な存在である。その運営方法を考察することは、データウェアハウスに劣らず重要な事項であり、今後、それについても研究したい。

［注］

１）ユーザの利用目的に合致していることを指す。「目的別」という人もいる。
２）更新しないという意味である。
３）E.F.Coddは、１９９５年に「１２のルール」を「１８の機能」と改訂したが、両者の間には　本質的な違いはない。
４）ＯＬＡＰには、純粋の多次元データベースによるもの（ＭＯＬＡＰ）と、ＲＤＢに多次元ビューをかぶせて多次元に見せるＲＯＬＡＰがある。ＭＯＬＡＰでは、次元が増加するたびにデータ量が急増するので、大規模なものは取り扱えない。ＲＯＬＡＰは論理的には大規模なものも取り扱うことはできるが、処理時間が遅いので、現実的にはあまり大規模にはできない。
５）ディテールデータとは、取引ごとに発生する明細データのことである。生データともいわれることもあるが、入力したままで加工をしないという意味で生データということがある。ここでは正規化などの加工を前提としているので、ディテールデータとした。
６）W.H.Inmon の定義は、データマートを指していると解釈したほうがわかりやすい。
７）ＯＬＤＰと似た用語としてＯＬＱＰ（Online　Query Processing ）がある。しかしＯＬＱＰでは検索が重視されるので、ここでは部品としての汎用性が重要であることから、このような名称にした。