スタートページ主張・講演論文等

データウェアハウス/データマート,OLAP,多次元データベース,エンドユーザ・コンピューティング

データウェアハウス運営に関する一考察

A Study on Data Warehouse Management

1998.10.20
東京経営短期大学 木暮 仁

『東京経営短期大学紀要』第7巻(1999.3)pp.47−58所載


要 旨

 データウェアハウスの概念が急速に普及し、実際にデータウェアハウスを構築している企業も多くなってきた。ところが、その効果が十分に発揮できず、かえって費用対効果が悪化したとか、情報システム部門が多忙になったという現象も発生している。データウェアハウスの運営に関してはコンピュータ雑誌でも取り上げているが、本論文では、筆者の実務経験から雑誌等であまり取り上げていない誤解しやすい事項や留意すべき事項を示した。


1 データウェアハウスの概要

1.1 データウェアハウスの定義

 データウェアハウスとは、文字通りにはデータの倉庫のことであるが、W.H.Inmon(1992)は、データウェアハウスを「サブジェクト指向(subject-oriented)、統合化(integrated)、恒常的(non-volatile)、時系列(time-variant)の特性を持つマネジメントの意思決定を支援するデータの集合である」と定義した1)。

 企業を取り巻く環境は激変している。それに対応するには、情報の利活用により適切な意思決定をすることが必要である。そのために、販売システムや経理システムなどのいわゆる基幹業務系システムで収集蓄積したデータを、利用者が使いやすいように整理して、任意に検索加工できるようにする利用形態が重視されてきた。この利用形態を情報検索系システムというが、1970年代のDSS(Decision Support System)や1980年代のEUC(End-User Computing)の普及を通して確立してきた。

 すなわち、データウェアハウスの概念は目新しいものではなく、以前から存在していたのである。しかし、当時のコンピュータ環境では、大量のデータを保管して短時間で検索加工するには限界があった。それが1990年代の初頭におけるダウンサイジングの普及、並列処理技術の進歩、ディスクの大容量化、データベース技術の発展などにより、その壁が大きく取り外されるようになり、改めて重視されるようになったのである。

1.2 データウェアハウスの効果

 データウェアハウスは、情報検索系システムの発展形態であるとともに、最近の情報利用動向の基本ともなるものである。

 システム開発では、ERP(Enterprise Resourse Planning)パッケージによる開発が注目されているが、一般にERPパッケージでは、時系列的なデータを多様に加工する機能を十分には持っていない。それを組み込もうとすると、いわゆるカスタマイズやアドオンが多くなり、費用も時間もかかり将来の改訂も煩雑になるなど、ERPパッケージの利点を享受することができない。それらの機能をデータウェアハウスで受け持つことにより、ERPパッケージへの仕様を簡素化することができる。

 情報技術による営業活動を支援するSFA(Sales Force Automation)では、顧客情報の整備とそれの多角的な検索加工がポイントになるが、それはデータウェアハウスの機能そのものである。

 ナレッジ・マネジメントは、現在では、その対象をコミュニケーション分野に求めているが、企業情報では数値的な情報が重要であり、いずれその分野へも波及しよう。そうなると、データウェアハウスもナレッジ・マネジメントの大きな要素となる。

 このような理由により、データウェアハウスは着実に普及してきた。1998年4月における「日経コンピュータ」誌のアンケート調査2)によれば、国内の上場/店頭公開企業とそれに準ずる企業の全体では、データウェアハウスを既に構築している企業は19.1%、構築予定がある企業は34.7%であり、従業員5000人以上の企業では、それぞれ36.7%、44.9%になるという(注1)。データウェアハウスは、もはや、通常の利用形態になってきたのである。

1.3 OLAPとMDDB

 E.F.Codd(1993)は、データウェアハウスのような分析を中心とする利用形態をOLAP(Online Analytical Processing)と命名し、OLAPでのデータの特性として「12のルール」3)を示し、MDDB(Multi-dimensional Database:多次元データベース)が適切であるとした(注2)。

 MDDBの構造は次のようなものである。東京支店の売上実績を、縦に商品、横に月をとれば2次元の表になる。同様に大阪支店、名古屋支店の表を作り、それらの表を重ねれば3次元になる(図1(1))。さらに売上、原価、利益のような会計区分を加えれば4次元になるというように表の次元は増大する。MDDBの基本操作には、パンをスライスするように現在の断面と平行した断面を表示するスライシング(2)、サイコロを転がすように他の断面を表示するダイジング(3)(4)、詳細に展開したり集約したりするドリリング(5)がある。市販されているMDDBのソフトウェアでは、これらの操作は、表の部分をクリックしたり、プルダウンした項目をクリックするというように画面操作だけで行えるようになっている。また、表示されている数表を、多様なグラフにすることも簡単にできるように工夫されている。

MDDBの基本操作の図
図1 MDDBの基本操作

1.4 VLDBとデータマイニング

 消費経済の成熟化に伴い、顧客ニーズは多様化している。国際化の発展や消費の低迷により競争は激化している。このような環境においては、マスとしての市場ではなく、個々の顧客(個客)のニーズを的確にとらえた製品の開発、販売政策、店舗管理などが重要になる。それには、個客の購買データをデータベースとして管理して分析することにより、有用な情報を得て、政策に活かすことが重要になる。このようにデータベースを駆使したマーケティングをデータベース・マーケティングという。

 データベース・マーケティングを有効に行うには、個々の販売のディテールデータを長期にわたり時系列に持つ必要がある。そのために、そのデータ量は膨大になり、数十GB(ギガバイト=10億バイト)から数TB(テラバイト=1兆バイト)にもなる。このような巨大なデータベースをVLDB(Very Large Database)という。

 VLDBを分析して有用な情報を得ることを、探鉱になぞらえてデータマイニングというが、これには単なる分類処理や集計処理だけではなく、多変量解析などの統計解析が必要であり、人工知能やニューロなどの技術も応用した分析ツールが開発されている。

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

 データウェアハウスの説明では、VLDBをデータマイニングすることと、MDDBによるOLAPを混同して説明していることが多い。そのために、数テラバイトにおよぶVLDBをMDDBにしてスライシングやドリルダウンが簡単にできるかのような誤解を招くこともある。

 ところが、現実に利用部門に設置されるサーバの容量はせいぜい数十GBであり、VLDBをこれに格納することは困難である。また、MDDBが現実に取り扱えるデータ量は数GB程度である(注3)。

 そのような事情により、データウェアハウスとデータマートに区分することが多い。このとき、データウェアハウスとは、全社的なデータの保管庫として、超並列プロセサや大規模なUNIXサーバを用いて、それにVLDBを構築する。それに対して、データマートでは、利用者が使いやすいように、その部門が必要とするデータだけを、利用部門に設置された比較的小規模なサーバに、MDDBのような利用者に使いやすい形式で保管する。すなわち、比喩的にはデータウェアハウスは中央卸売市場のようなものであり、データマートは近所のコンビニエンスストアのようなものだといえる。

 このように、データウェアハウスとデータマートとは峻別すべきものなのであるが、これらをまとめてデータウェアハウスという場合もあるし、データマートのことをデータウェアハウスということもあり、それが誤解を与えていることもある。たとえば、前述したW.H.Inmonの定義は、データウェアハウスよりもデータマートとしての定義と考えるほうが適切である。


2 データウェアハウス運営における留意点

 データウェアハウスの運営に関しては、「目的を明確にすること」とか「小さく始めて大きく展開すること」などが指摘されている。しかし、筆者はEUCや情報検索系システムの普及に従事してきた経験から、それにもまして重要であると認識している留意点について指摘する。

2.1 部門セクショナリズムによる阻害

 電子メールや電子掲示板などのコミュニケーション系システムでの運用では、セクショナリズムの強いクローズな組織文化では円滑な発展が阻害されることはよく指摘されている。データウェアハウスにおいては、そのデータは基幹業務系システムで収集されたものであるから、データの提供ではこのような問題はないが、データの公開にあたっては、利用部門の反対による阻害が発生することがある4)。

 たとえば、ある部門が値下げ販売をしたのを他部門に知らせたくないなどの理由により、「数量は公開してもよいが単価は公開するな」とか「集約したデータは公開してもよいがディテールデータは公開するな」などの圧力がかかることがある。これにより、公開するデータベースの構造は複雑になり、複雑なアクセス制限を設けることになり、使いにくいシステムになってしまう。

2.2 利用者趣味による弊害

 データウェアハウスは利用者が使うことにより効果が得られるのであるから、利用者の要求に合わせた操作方法や出力体裁にするのは望ましいことである。しかし、ややもすると、利用者の過度な要求のために、その構築や維持に多大な労力がかかり、かえって発展を阻害する危険もある。

 一般に、自由度を高くして多様な情報が得られるようにすることと、操作を簡便にすることとはトレードオフの関係がある。利用者は、「1をクリックすれば○○集計表、2をクリックすれば××分析表」というような個別処理メニュー提供方式を要求する。このような方式は便利であるが、利用者が多く要求する帳票も多様になると、そのような環境を整備することが事実上不可能になる。しかも、いったんこのような個別処理メニュー提供を行うと、後になってMDDBツールを普及させようとしても、利用者は不便になることを理由にして、その利用に反対する。

 また、利用者が必要以上に体裁に凝ることがある。MDDBツールでは、縦に得意先、横に年月をとったときも、縦に商品、横に支店をとったときも同じデザインになる。ところが利用者は、それぞれ異なるデザインにしたがる。特に、どこに罫線を引くかとか、フォントを変えるなどの、情報としての本質ではなく、体裁を重視した要求になることが多い。そうなると、個別の出力帳票ごとに特別な組込処理を作ることになり、データベースを構築するよりも、これへの対処のほうに労力や時間を費やすような本末転倒な事態になる。

 これを避けるために、MDDBツールで作成した表をパソコンのスプレッドシートに変換して、パソコンで編集することが考えられるし、多くのツールがその機能を持っている。ところが、利用者のなかにはスプレッドシートの利用を習得しない者もいるし、習得しても面倒がって、自動的に行える機能を組み込むことを要求したりする。逆に、スプレッドシートに習熟した利用者は、多様なテクニックを駆使して体裁をよくするだけのことに多大な時間を使い、生産性の向上や創造性の向上あるいは結果の実務への反映といった本来の目的に反した作業をすることもある。

 このような利用者の趣味による弊害はデータウェアハウスに限ったことではなく、EUC全般にいえることであるが、特にデータウェアハウスの運営にあたっては、これが費用対効果に大きな影響を与えることに留意したい。

2.3 メタデータの重要性

 利用が普及しない原因としては、操作が難しいというよりも、データの内容や項目の意味が不明確なことにより、どれを用いてよいのかわからないとか、出力した結果が自分の期待した値と違い困惑することがあげられる。利用者にとっては、たとえば「在庫」の項目では引当在庫の取り扱いはどうなっているのか、「売上ファイル」では、返品処理はデータとして入っているのか、あるいは売上から返品分を差し引いてあるのかなどの業務としての情報がほしいのである。

 ほとんどのMDDBツールは、メタデータを持っている。メタデータとは、データについてのデータであり、データに関するいっさいの情報を入れたものである。ところが、通常のMDDBツールでは項目の一覧や属性などが中心であり、項目名やテーブルの説明の記述欄はあるにしても、せいぜい1行足らずのものでしかない。これでは利用者にはあまり役に立たない。それをカバーするためには、MDDBツールとは別に解説書ファイルを作って参照させることが必要になるが、その機能がツールに標準装備されていない(注4)。

 また、多くの利用者が、元のデータベースを加工して新しいデータベースを作ることが多い。このときに、その加工プロセスを新しいデータベースのメタデータに継承することができれば、利用者は他の利用者が抽出したデータベースを利用することにより、重複作業が防げるのであるが、そのような機能を持つMDDBツールは未だ存在していない。

2.4 データウェアハウスの必要性とデータの持ち方

 データマートに置くことのできるデータ量は小さいので、利用者の多様なニーズに応えるには、データの入れ替えも必要になる。また、利用者のニーズの変化に応じてデータマートに持つデータもそれに合わせて変えていく必要がある。

 データマートのデータはデータウェアハウスから取り出すのであり、データウェアハウスが持つデータの大部分は基幹業務系システムで収集しメインフレームに保管されている。それならば、メインフレームから直接にデータマートにダウンロードすればよいので、データウェアハウスは不要ではないかとも考えられる。

 ところが、現実にはそれでは不便なのである。W.H.Inmonら(1994)も、基幹業務系システムでの統合化されたデータベースであるODS(Operational Data Store)とデータウェアハウスとは異なった概念として分析することが必要だとしている5)。彼は、ODSのデータは時系列データではなく、ディテールデータだけで集約化をしていないことを理由にしているが、基幹業務系システムでは、正確性・迅速性が重視されるという本質的な意味で、基幹業務系システムでのデータをそのままデータウェアハウスで用いることはできないのである。

 基幹業務系システムでは、正確性・記録性が重要である。データを入力した後で誤りを発見したときには、誤りデータを単純に消去するのではなく、誤りのデータ、削除のためのデータ、修正したデータを保管する必要がある。それに対してデータウェアハウスでは、結果の状況が重要なのであり、誤り修正履歴は取り扱いを面倒にするだけである。

 基幹業務系システムは「販売システム」や「経理システム」などのように、縦割り業務で構築されている。システムの効率性を重視すれば、その業務に特化した処理形態やデータの持ち方にする必要がある。とくに大量のデータを扱うOLTPではそうである。それに対して、データウェアハウスでは多業務にまたがったデータを統合的にとらえることが重要であり、個別業務に特化したデータでは取り扱いにくい。

 このように、基幹業務系システムのデータをデータマートに転送するには、単純なコピーではなく、複雑な変換処理が必要なのである。データマートで要求されるデータは頻繁に変化するので、そのたびに複雑な変換を行うことは運用上大きな問題になる。

 それを避けるためには、基幹業務系システムとデータマートでのOLAPデータとの間に正規化したデータベースを構築し、それをデータウェアハウスとして保管するのがよい6)。それにより、基幹業務系システムからデータウェアハウスへの変換、データウェアハウスからデータマートへの変換が容易になるのである。

2.5 VLDBのデータマイニング

 先に、データウェアハウスとデータマートとを区別すべきことを述べたが、MDDBツールとデータマイニングも区別してとらえるのが適切である。両者ともデータを多角的に分析することにより問題を発見することが目的であるが、MDDBツールでは単純な集計計算を手軽にできることを目的としているのに対して、データマイニングは統計的方法により、より高度な分析を目的としているのであり、それぞれに適したツールがある。

 また、データマイニングの対象がVLDBであるかのようにいわれることが多いがそれも適切ではない。当然ながら、データマイニングのツールもデータ量が小さいほど処理効率はよい。検討する事象の発生確率が比較的大きい場合には、少数のサンプルで分析しても高い信頼度が得られることは確率論の教えるところである。

 VLDBを直接に分析するのではなく、VLDBから比較的少量のサンプルを選択して、パソコン等に取り出し、それを多様な分析を試行錯誤的に行い、その結果をVLDBにあてはめて検証するほうが、便利でもありコスト的にも安上がりである。VLDBはデータウェアハウスに置き、そのデータは正規化するべきだといった。それは、VLDBそのものをデータマイニングの対象とするのではなく、VLDBから適切なデータをデータマイニング用に取り出すことが重要であり、それを取り出すには、データが正規化されているのが便利だからである。

 ところが、一部の企業を除いて、統計・確率・OR(オペレーションズリサーチ)の技術を持つ者は少ない。1960年代までは、コンピュータにこれらの技法を応用することが華やかであったが、その後のコンピュータの発展に伴い、そのような技術を持つ者がむしろ減少しているのが現実である(注5)。データマイニングの重要性が認識されるに伴って、これらの技術が復活するのを期待したいのであるが、最近のデータマイニングツールの紹介では、操作性や画面体裁ばかりを重視して、そのアルゴリズムや適用にあたっての留意事項などがおざなりになっているようである。

2.6 いわゆる「大福帳データ」について

 『日経情報ストラテジー』誌は、「大福帳データ」という概念を提唱している7)8)9)。これは、 基幹業務系システムでのデータを考えているようでもあるが、「生データを大福帳の法則で記録すれば、経営実態を詳細に調べることが可能になり、ビジネスの透明度が大幅に向上する。このデータをデータウェアハウスに生かすことで、問題点の発見や分析、追跡などがより早く、スムーズに実行でき、対策をすぐに立てられるようになる」といっている。このような記事に影響されたためか、「データウェアハウスには大福帳データを用いるべき」だとする論調が、実務者の間ではよく見受けられる。

 しかし、この大福帳データをデータウェアハウスのデータとするのは問題が多い。売上などのイベントが発生のたびに発生するデータを集約せずに蓄えているデータのことを、大福帳では「生データ」という表現をしている。「伝票の1枚を1レコードにする」としてデータの1次正規化を否定しているが、それでは多様な検索加工をするのは大変である。また、「間違った伝票を修正したときも誤り伝票に印をつけて残しておく」としているが、それでは前述のように使いにくいものになる。さらに、OLTPとOLAPとで同じデータを使うというのでは、W.H.InmonやE.F.Coddの主張とは基本的に相容れないことになり、それがデータウェアハウスだというのは不適切だといえる。

 多様な分析をするためには、その基となるデータはディテールデータで持つ必要がある。しかし、それは基幹業務系システムで入力したままの「生データ」ではなく、分析に適した加工をした後でのデータである。操作性の都合によりデータを非正規型で持つ場合も、一度正規化してから、改めて非正規化することが重要である。適切な処理を施したデータでないと、利用面で煩雑になり、あるいは間違った結果を得る危険すら生じるのである。

 このように、大福帳データは、基幹業務系システムの補助としての情報検索系システムとしては妥当な場合もあるが、データウェアハウスのデータとしては不適切な概念なのである(注6)。

2.7 データウェアハウスの運用組織

 EUCの推進組織としては、情報システム部門での組織と利用部門での組織(情報化リーダとかシステムアドミニストレータなどと呼ばれる)が必要なことはよく指摘されている。筆者は、それに加えて、営業本部とか本社経理部などの業務統括部門にEUC推進組織を置くことが重要であると主張してきた10)。この組織は、データウェアハウスの運営において特に重要になる。

 先に個別処理メニュー提供方式を批判したが、これは便利な方式であり、全面的に否定することはできない。利用頻度の多い処理やパソコン操作に習熟していない利用者に利用させるには効果的な方式である。

 また、データウェアハウスやデータマートの管理を誰が行うのかも問題である。情報システム部門がデータマートまで管理すると、利用者はいままで情報システム部門への依存が強いので、おそらく操作性や画面体裁などの要求が続出するであろう。

 とかく情報システム部門にとって、利用者のニーズを否定するのは困難であり、個別処理メニューにしてもデータマートのデータにしても、利用者の要求に無批判に応じる傾向がある。その結果、情報システム部門はますます多忙になり、利用者は情報システム部門依存から抜け出さない。

 それに対して、業務統括部門は、業務の方針や仕事の仕方など、その業務のリエンジニアリングを実現する任務を持っている。その一環としてデータウェアハウスの活用も推進する立場にある。方針を実現させるために個別処理メニューを提供したり、データマートのデータベースを整備するのもその任務であるといえる。利用者からの要求がその方針に合致していれば積極的に採用するが、合致しなければ拒否することもやりやすい。

 利用者のニーズを業務統括部門が取捨選択して情報システム部門に依頼する体制も考えられるが、それではやはり情報システム部門に過剰に押しつける傾向になる。それよりも、情報システム部門は業務統括部門がメニューやデータベース構築が容易にできる環境を整備して、実際の作業は業務統括部門が行うほうが適切である。

 先に、メタデータをもっと利用者に役立つ機能を持たせるべきだとか、データウェアハウスのデータは正規化すべきであると述べたが、これらは業務統括部門での作業を容易にすることに大きな効果を持つのである。

 以上、データウェアハウスおよびデータマートの運営を円滑かつ健全に発展させるために留意すべき事項を示した。単に留意点をあげただけでなく、解決のための対処についても示したつもりである。


引用文献

参考文献