Business

ビジネス

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

安達敏光
2009年7月6日 / 11:00
 
 
データウェアハウスと、単純にデータを集めただけのデータベースの違いはどこにあるのでしょうか。

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

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

データウェアハウスの定義 「4つの特性」

1.サブジェクト指向

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

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

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

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

【図1】 データウェアハウスはデータをサブジェクトに分解して保有する
【図1】 データウェアハウスはデータをサブジェクトに分解して保有する
*クリックして拡大
2.統合すること

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

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

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

例えば、調達システムで「仕入れ先企業」と称するものと、販売システムで「販売先企業」と言う実体があったとします。これはどちらも「取引先」であり、「企業」という同じ概念を指していますね。さらに、取引先には企業だけでなく個人のお客さまもいるかもしれません。そうすると「取引先」とは個人、法人の両方を含む概念、と言ったほうがよさそうです。

従業員とか株主というのはどうでしょうか。これらは取引先ではありませんが、自社にとってのステークホルダー(関係者)という意味では、相通じる概念ではないでしょうか。
そこで、データウェアハウスでは「販売先名」「仕入先名」とか「お客さま名」をそのまま別項目として保有するのでなく、抽象化して一つの概念に統合します。ここでは「関係者」という概念にしておきましょう。このように、データウェアハウスはデータを抽象化してサブジェクトごとに格納します。


【図2】抽象化するのが統合上のテクニックのひとつ
【図2】抽象化するのが統合上のテクニックのひとつ
*クリックして拡大

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

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

しかし各種分析を行う時には、そのような履歴が大切な意味を持つこともあります。データウェアハウスでは、データの更新や消去はしないよう設計します。

顧客の住所変更があった時は、古いデータはそのまま残して、新しい住所データを最新住所として追記します。間違った売上データを取り消す時は、間違ったデータを消去するのではなくて、「間違った売上データを取消す」意味を持ったデータを追加するようにして、取消があったという事実を失わないようにするのが原則です。

4.時系列を持つ

企業の業務システムは、期次、月次、週次、日次というように、データを算出するサイクルが決まっているものも多くあります。データウェアハウスはこれらのデータを格納しますが、新しいデータが入ってきた後、古いデータを消さずに、過去のデータとして蓄積していきます。

さすがにすべてを永久に保有し続けるとはかぎりませんが、だいたい3年分とか5年分くらい保有するのは普通です。

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

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


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

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

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

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


【関連記事】
厳しい経済状況でも商談が進むデータウェアハウスとは何か
日本テラデータ、パートナー専用の Teradata 検証センターを開設
岐阜の十六銀行、Teradata DWH で新顧客 DB システムを導入
日本テラデータ、PB 級データ量を分析できる DWH アプライアンス新機種を販売
DWH の日本テラデータ、ストレージ仮想化技術を追加した「Teradata 13.0」を販売

New Topics

Special Ad

ウマいもの情報てんこ盛り「えん食べ」
ウマいもの情報てんこ盛り「えん食べ」 「えん食べ」は、エンジョイして食べる、エンターテイメントとして食べものを楽しむための、ニュース、コラム、レシピ、動画などを提供します。 てんこ盛りをエンジョイするのは こちらから

Hot Topics

IT Job

Interviews / Specials

Popular

Access Ranking

Partner Sites