検索

データウェアハウスと単なるデータベースの違い



データウェアハウスと単純にデータを集めただけのデータベースの違いはどこにあるのでしょうか。

企業内の色々な業務システムからデータを丸ごとコピーして集めればデータウェアハウスになるものではありません。単にデータを寄せ集めただけではデータが増えれば増えるほどデータの整合性の維持やメンテナンス、使い勝手など様々な面で混乱や不都合を来たすばかりです。

そんなわけで業界にはデータウェアハウスとして成り立たせるために備えるべき定義といわれているものがあります。

データウェアハウスの定義 「4つの特性」
1.サブジェクト指向

データをサブジェクト(主題)ごとに分解、整理して格納します。目的別に格納しないのがポイントです。これはちょうど図書館での資料整理の方法に似ています。図書館では本をその内容によって分類していますね。海外出張前の情報収集用とか卒業論文の資料集め向け、というような利用目的別には整理していないのと同じイメージです。

例えば基幹系システムの販売実績データには、販売した日付、顧客の氏名、住所、販売した商品コード、商品名称、商品の色やサイズ、定価、販売数量、販売価格、販売した店舗コード、販売担当者コードなどの情報がズラズラと並んでいるでしょう。データウェアハウスではこれをそのまま「販売データ」として格納しません。「顧客」「商品」「店舗」「従業員」「取引」というようにサブジェクトに分解して格納します。

こうすれば、別の例えば顧客管理目的のシステムでも顧客の名前や住所、電話番号等の情報を保有している場合、販売実績管理を目的とするデータと顧客管理目的のデータの両方で顧客名や住所情報を重複保有せずに済みます。

むろん分解しても元の形が復元できるよう、キーとなる項目で結合して復元できるような仕掛けもしておきます。このようなデータの扱いはリレーショナルデータベース管理ソフトが得意とするところです。

2.統合すること

データウェアハウスは企業のあらゆるデータを統合することを目指します。単に多数の業務システム等からのデータを一つの場所に集めて置くだけでは意味がありません。物理的に一つのシステムに格納しているかどうかではなく「論理的」に統合することがポイントです。

別々の業務システムからデータを持ってくると、同じ概念、同じ意味の情報が重複することがよくあります。また、一見異なる項目名が付いているけれど実は中身は同じもの、ということもあります。

データウェアハウスを設計する時には、データの中身をよく調べて、先に述べたサブジェクトごとに整理してデータベース化します。この時データの意味を「抽象化」するのがポイントです。

例えば、調達システムで「仕入先企業」と称するものと、販売システムで「販売先企業」という実体があったとします。これはどちらも「取引先」であり「企業」という同じ概念を指していますね。さらに取引先には企業だけでなく個人のお客さまもいるかもしれません。そうすると「取引先」とは個人、法人の両方を含む概念と言った方が良さそうです。さらに、従業員とか株主というのはどうでしょうか。これらは取引先ではありませんが、自社にとってのステークホルダー(関係者)という意味では相通じる概念ではないでしょうか。

そこでデータウェアハウスでは「販売先名」「仕入先名」とか「お客さま名」をそのまま別項目として保有するのでなく、抽象化して一つの概念に統合します。ここでは「関係者」という概念にしておきましょう。このようにデータウェアハウスはデータを抽象化してサブジェクトごとに格納します。

3.消さない・更新しない

基幹系システムは業務を遂行するのに必要なデータがあれば良いので、不要になった古いデータはいつまでも保有しないのが普通です。例えばお客さまの住所が変わった時、基幹系システムでは古い住所を新しい住所に書き換えます。

しかし各種分析を行う時には、そのような履歴が大切な意味を持つこともあります。データウェアハウスではデータの更新や消去はしないよう設計します。お客さまの住所変更があった時は、古いデータはそのまま残して新しい住所データを最新住所として追記します。間違った売上データを取り消す時は、間違ったデータを消去するのではなくて「間違った売上データを取り消す」意味を持ったデータを追加するようにして、取消があったという事実を失わないようにするのが原則です。

4.時系列を持つ

企業の業務システムは、期次、月次、週次、日次というようにデータを算出するサイクルが決まっているものも多くあります。データウェアハウスはこれらのデータを格納しますが、新しいデータが入ってきた後、古いデータを消さずに過去のデータとして蓄積していきます。さすがに全てを永久に保有し続けるとは限りませんが、だいたい 3年分とか 5年分くらい保有するのは普通です。

以上の 4つがデータウェアハウスの基本的な性質と言われているものです。

これらの特性を踏まえて設計されているかどうかを観察すれば、単純に複数の業務システムからデータを寄せ集めてきただけのデータベースなのか、データウェアハウスの本来のメリットである変化への柔軟性や組織横断的なデータ共有環境を提供できるデータベースなのか見分けられると思います。

データウェアハウスの提唱者

ご紹介した 4つの基本性質は、それを唱えた元祖となる人がいます。最初にデータウェアハウスの概念を提唱したビル・インモン(William H. Inmon)という人です。1990年頃、最初のデータウェアハウスに関する本を出し、その後何冊かデータウェアハウスに関する本を出版していて日本語版も入手可能です。

インモン氏は今日ご紹介した 4つの性質に加えて「明細データ」を持つことが大切であると主張しています。

実際、データウェアハウスを活用する現場に接している筆者も、明細データの活用はデータから知識を引き出す上での大切な要素と思っていますので、次回はこの点にも触れようと思います。