データウェアハウスとは？

皆さんこんにちは！
今回は、前回解説したData Vaultをより理解していただくため、データウェアハウスとは何か？について紹介します。
データウェアハウスは、広い意味でデータ基盤と呼ばれたりします。
前回ではクラウド基盤と呼んでいましたが、クラウド基盤とはクラウドアプリケーションで実装するデータ基盤と捉えていただければ良いかなと考えています。
データウェアハウスについて知ることで、前回のブログもより深く理解できると思うので、ぜひ最後までお付き合いください！
参考までに前回のブログのリンクも貼っておきます！

データウェアハウスの前提知識

そもそもデータウェアハウスを簡単に説明すると、様々な基幹システム（業務で利用されるシステム）からデータを収集し、1つの場所に格納する管理システムのことです。

データを格納するための倉庫と捉えていただけると良いかなと思います。
データウェアハウスができるまでは、各システムが独自のルールや粒度で管理されるデータを基に分析していました。
これは非常に手間がかかり、全社横断という視点で中々データを分析できませんでした。
例えば複数のシステムを見に行くためのインターフェースを繋いだり、AシステムとBシステムで管理する「顧客」は同じ意味なのか？ということを考えたりといったような状況です。

データウェアハウスを上手に活用することで、上記を解消し組織横断的なデータ活用ができるようになります。

データウェアハウスの歴史

そんなデータウェアハウスを語る上で、欠かすことができない2人（ビル インモン、ラルフ キンボール）をご紹介します。
データウェアハウスは大きく彼らが提唱した2つのパターンに派閥がわかれます。

コーポレートインフォメーションファクトリー

まず、ビル インモンが提唱するコーポレートインフォメーションファクトリー（CIF）についてです。
このCIFで特徴的なのは、全社のデータを全て一箇所に収集し、統合変換を加え、分析ニーズに合う形で保持する点です。
簡単な絵で説明すると以下のような形です。

DMBOK2 P418参照

ディメンショナルデータウェアハウス

次に、ラルフキンボールが提唱するディメンショナルデータウェアハウスです。
こちらの特徴的な点は、まず以下のようなDWバスマトリックスを使い、業務プロセスと、業務プロセスで利用されるデータを整理し、分析したい業務に合わせたデータのみを収集する点にあると考えます。

DMBOK2 P420参照

データウェアハウスの問題点

ではなぜ、上記2つのような考え方とは異なるData Vaultが最近注目されるのでしょうか？
それは、各システムから収集したデータの整合性を確かめ、に正規化し、データウェアハウスへ格納する手間を省くためです。
整合性を確かめたり、正規化を行うことは、各システム側のデータがローカル固有のルールを読み取る必要があるなど真面目に取り組むと時間がかかります。
変化の激しいこの時代に、ゆっくりじっくりデータウェアハウスに取り組める余裕のある企業が少なくなっているため、Data Vaultが注目されています。
Data Vaultは、以前のブログでも説明した通り、下記3つの要素からなります。

1. Hub：ビジネスキーとなる項目を保持する。

2. Link：Hub間のリレーションシップを表す。

3. Satellite：HubまたはLinkの詳細項目を保持する。

各システムで同じようなテーブルが存在する場合、Hubの部分つまりビジネスキーだけは合わせておき、その他各システム側で保持する属性情報はLinkに保持させておく。
さらに、標準化したい項目が出てきた場合、新たに標準化用のLinkを用意する。

こうすることで、素早くかつ柔軟性を持たせたままデータウェアハウスを設計することができます。

最後に

データウェアハウスを上手く活用することで、社内のデータをより効率的に分析することができます。
AIが活発になってきた昨今、データウェアハウスの存在感は今後益々高まっていくことが予想されます。一方、データウェアハウスを活用できる形で整備できるかは今後企業の成長に大きく関わる部分だと考えます。
だからこそ、ITにそれほど関わりがない方でもこのような知識を知っておくことは損ではないはずです！
本日は以上になります。最後まで読んでいただきありがとうございました！