「データウェアハウス」とは
■概要
・データベースの1つの利用形態
・統合データベース
・活用法
・定義
■データウェアハウスの必要性
・直近を保管する「データベース」
・過去を保管する「データウェアハウス」
■データ活用目的
「データウェアハウス」の主な特性
■①サブジェクト別分類
・基幹系明細データをサブジェクト別に分類
・データ重複を回避できる
・キー項目による明細データ復元
■②論理的統合(抽象化)
・企業内のあらゆるデータを統合
・単純データ統合の弊害
・データ抽象化による論理的統合
・項目名統一
・意味的まとまりとしてのデータ抽象化
■③データ永続性(削除/更新しない)
・基幹系システムは利用する最新データのみ保持
・データウェアハウスは履歴を保持
・履歴データの活用
・データウェアハウスでのデータ変更方法
■④時系列データ
・時系列保存
「データウェアハウス(DWH:Data WareHouse)」とは、ビジネスインテリジェンスに活用するための「データ倉庫」を意味し、目的別かつ時系列に編成/統合され、削除や更新されないデータ集合体(データベースシステム)を指す。
データウェアハウスはデータベースの利用形態の1つで、ETLプロセスを通じて、複数のデータソース(基幹システム/製造管理システム/販売管理システム/会計システム/その他サブシステムなど)からトランザクションを抽出して、再構成/再蓄積したデータの集合体として保管する。
データウェアハウスは、さまざまなデータソースから抽出データをそのままの形で保管するのではなく、同じ意味合いを持つデータを集約するなどして、横断的に扱えるようにするなど統合し、データが持つ主題ごとに整理し直して格納する。
データウェアハウスに集積されたデータを抽出し、分析することで、ビジネスインテリジェンスとして活用する。
データウェアハウスは、ビル・インモン(William H. Inmon)氏が提唱し、その著作によると、「データウェアハウスは、意志決定(Decision)のため、目的別(Purpose-oriented)に編成され、統合(Integrate)された時系列で、削除(Delete)や更新(Update)しないデータの集合体」と定義している。
従来の企業ITシステムにおいては、サーバ上に構築されたデータベースは、ハードウェアスペック(データベース容量など)の制約により、「過去データ(14ヶ月以前など)を削除して容量を確保する」などの使われ方をされてきた。
サーバ能力が向上してきた今日でも、IT化/デジタル化によるデータ量増加の問題があるため、ハードディスク容量制限問題は依然として存在しており、激増するデータ量が1つのデータベースには収まらない状況が続いている。
以上のような理由があり、一般的な利用用途のデータベースは「直近(13ヶ月以内など)のデータを格納/管理する」という使われ方をしている。
昨今において「過去データ(過去から現在において累々と蓄積されてきたデータ)が保有する価値」に対して注目が集まり始めた。
「現在のデータを格納しているデータベースには負担をかけないように既存データベースを維持しつつ、大量の過去データを蓄積し高速に参照できる大型データストレージ」が必要とされ、「倉庫」としての性格が強いデータウェアハウスという概念が生まれた。
データウェアハウスは、「データ活用」を意識した大型データストレージであり、「データ活用」するための仕組みが用意されている。
さまざまな分析に活用されることを前提としており、データウェアハウスに格納されたデータの中から、必要となる情報が呼び出され、ビジネスインテリジェンスとして利用される。
取り扱うべき情報量が爆発的に増加している状況に対応し、本当に必要な情報を迅速に収集するために、多くの企業でデータウェアハウスが積極的に活用されるようになってきている。
主に次の4つの特性を持つデータストレージがデータウェアハウスと呼ばれる。
データウェアハウスは、データを「目的別」ではなく「サブジェクト(主題/内容)別」に分類/整理して格納する特徴がある。
基幹系システムの販売実績明細データには、多くの情報が保持されている。
・販売日
・顧客氏名
・顧客住所
・顧客電話番号
・商品コード
・商品名称
・商品サイズ
・定価
・販売数量
・販売価格
・販売店舗コード
・販売担当者コード など
このデータがデータウェアハウスに格納されると、以下のようにサブジェクト別に分解して格納される。
・顧客
・商品
・店舗
・従業員
・取引 など
サブジェクト別にデータを格納することで、データ重複を回避できる。
販売実績明細データが保持している「顧客名」「顧客住所」「顧客電話番号」については、別のサブシステムでも同一顧客のデータを保持している場合がある。
データウェアハウス内では、「顧客」というサブジェクト単位で格納するため、さまざまなシステムが保持している顧客データを集約でき、重複データの存在を回避できる。
データウェアハウスでは、明細データはサブジェクト別に分解されて格納されるが、キーとなる項目を設定しておくことで、データ結合を行い元の明細データを復元できるようにすることも可能となっている。
データウェアハウスは「企業内のあらゆるデータを統合する」ことを目的として作成される。
データ統合において、企業内のさまざまな業務システムからデータを集めて1つのデータストレージとしてまとめるだけでは意味がない。
単純にデータを寄せ集めただけでは、一見異なる項目名だが実は中身は同じ意味(内容)となっている情報が重複してしまうことにより、データが増加するほど、データの整合性維持/メンテナンス/使い勝手などが悪化するだけとなる。
データウェアハウスでは、物理的に1つのデータストレージに格納しているというよりも、企業内におけるあらゆるデータが「論理的」に統合されていることが重要となる。
データの中身について吟味を行い、データを抽象化した上で、サブジェクト単位での整理の結果、論理的に統合された情報体にする必要がある。
データウェアハウスを構築するために、さまざまなデータソースからデータの抽出を行うが、それぞれのシステムにおいて、「取引先」「取引先企業名」「顧客名」などのように項目名が異なる場合がある。
この場合、変換テーブルやデータウェアハウス用IDなどを使用して、「取引先企業名」と「顧客名」の項目名を「取引先」として抽象化して統合する必要がある。
「調達システムでの仕入先企業」と「販売システムでの販売先企業」は、項目名は異なるが、実質的には、どちらも「企業」というサブジェクトに抽象化できる。
仕入先や販売先は企業だけではなく個人の場合もある。個人の場合「企業」というサブジェクトには含まれないため、「企業」ではなく「取引先」という単位で抽象化すると個人も含めることができる。
データウェアハウス構築においては、このようにデータを意味的に抽象化することで、サブジェクト単位でまとめてデータを格納する。
基幹系システムは、業務を遂行するために、データの参照時点での状況を把握できるデータのみが保持されていればよいため、一般的に、不要になった古いデータは保有しない。
例えば、取引先住所が変更された場合、最新の住所情報のみが保持され、古い住所情報は破棄される。
そのため、保持データ量は時間と比例してさほど増大しない。
各種データ分析においては、データ履歴が重要な意味を持つ可能性が高い場合が多いため、データウェアハウスは「過去データの蓄積と現在との比較」を目的としている。そのため、データの削除/更新は行われずに、保持データ量は時間と比例して増大する。
データウェアハウスに集積された履歴データから、抽出/分析/比較などを行い、計画立案や意思決定などのために有用な知見を得るために利用される。
購買関連データの場合では「ある顧客の過去の購買履歴から今後の購買興味を予想」などに活用する。
取引先の住所変更があった場合、旧住所はそのまま残したままで、新住所を追記する。
また、売上データを取り消す場合は、対象データを消去せずに、「対象データを取り消す」という意味を持つデータを追記し、取消があった事実が失われないようにする。
データウェアハウスでは、新しいデータが入力されてきた場合でも、既存データを消去せずに、過去のデータとして蓄積していく。蓄積期間としては、数年単位での保存が一般的とされる。
特に、入出金システムなどの場合において、時系列保存が非常に重要となる。口座開設以来の出金と入金をすべて記録しておき、過去の任意の状態を再現できる必要がある。
大型データストレージである「データウェアハウス」は、ETLというプロセスを通じて洗練された情報の出力先として利用される。
ETLとは、企業内外に存在する複数のシステム(データソース)からデータを抽出し、変換(加工)後にデータウェアハウスなどに出力を行う一連のプロセスを意味する。
「データマート(Data Mart)」とは、データウェアハウスと関連した考え方で、データウェアハウス内に蓄積された各データの中から、「目的」「用途」「利用部門」に合わせて必要なものだけを抽出/集計し、利用しやすい形に格納したデータベースを指す。
データマートは、ユーザーが使うデータを予測し、「販売分析用データマート」や「購買分析用データマート」などの目的別に作成されるため、ビジネスユーザーが即座に検索や集計を行い、詳細分析を行いやすいメリットがある。
データウェアハウスとデータマートを組み合わせることで、ビジネス情報を一元管理したまま、ビジネスユーザーが分析を行いやすい環境を構築できる。小規模システムではデータウェアハウスを構築せずに、データマートだけを構築する場合もある。
参考元サイト
Analytics News ACCESS RANKING