データウェアハウス(DWH)の4つの要件について

こんにちは、DI部の川崎です。

DI部内で、データウェアハウス（DWH）の勉強会を行いました。その中から、データウェアハウス（DWH）の4つの要件についてご紹介します。

テキストはいつものこちらの本です。

「10年戦えるデータ分析入門」青木峰郎 著

http://www.sbcr.jp/products/4797376272.html

DWHの4つの要件：

1. サブジェクトごとに編成されていること(subject oriented)
2. データが統合されていること(integrated)
3. 時系列データを持つこと(time variant)
4. データが永続すること(non-volatile)

それぞれの項目について、詳しくみていきます。

1. サブジェクトごとに編成されていること(subject oriented)

• サブジェクト(subject)とは「顧客」とか「商品」のようにデータとしてまとまりのある分野、分析の軸のこと。
• 言葉を補って「(アプリケーションごとではなく）サブジェクトごとに」と言うとわかりやすい。
• OLTPのデータベースは基本的にアプリケーションと応答速度と安定性が優先で、特定のアプリケーション（販売、仕入れ、在庫管理など）に特化した設計。
• 複数システムの情報を合わせ、整理して「商品についてのデータ」がわかりやすくなるようまとめる、というのが「サブジェクトごとに編成する」こと。
• このようにデータを再編成をすることによって、DWHではアプリケーションにとらわれず、様々な角度からデータを分析できるようになる。

2. データが統合されていること(integrated)

• 分析システムでは分析対象のデータを会社中のシステムから集めてくる。
• 複数のアプリケーションにまたがり、データベースも1種類のわけがなく、データフォーマットもいろいろある。
• このような状況では、１つの同じデータが全データソースを通じて同じ表現になっていることは期待できない。
• 「ユーザーID」を例にとると、整数か文字列か、整数なら32ビットか64ビットか、そもそもIDというのは内部的に使っている整数なのか、ログインに使うメールアドレスなのか。
• 分析する上では、現実に１人であるユーザーはきちんと１人としてカウントしたい。
• そこでデータを統合する必要が出てくる。
• ユーザーIDが複数あるなら変換テーブルを経由したり「名寄せ」をして１つに連結し、分析用にIDを振りなおし、データ型と値の表現を統一する。

3. 時系列データを持つこと(time variant)

• 要するに、過去のデータを記録している、ということ。
• この特徴を理解するには、OLTPのデータベースの特徴と対比して考える。
• OLTPでは応答時間が命なので、データベースには常に「最新の状態」だけを記録。
• 例えば銀行口座を管理する勘定系システム（銀行の基幹系）であれば「現在の口座残高」を持っている。
• 出金や入金があるたびにこの値を更新する。
• 出金リクエストが発生したら、現在の口座残高を見て、次の処理を決める。
• 一方、DWHでは、現在の残高は二の次。
• 典型的なDWHでは、口座開設以来の出金と入金をすべて記録する。
• DWHにおいて元データとなるのは過去の記録、履歴のほう。
• なぜなら、履歴から現在の値を計算することはできるが、その逆はできないから。
• データの履歴を持っていると、過去の任意の状態を再現できるようになる。

4. データが永続すること(non-volatile)

• 要するに、一度記録したら原則として消さない、更新しない、ということ。
• この特徴は、3つめの履歴データと密接な関連がある。
• DWHでは過去の履歴をすべて記録するので、必然的に、更新したり消したりすることがなくなる。
• なぜなら、過去の出来事(取引)は一度発生したらそれはもう事実であって、変えようがない。
• なお、消さないというのはあくまで原則。

まとめ：DWHの４つの特徴

 DWHとは、
 データを主題別に編成しなおしてあり、
 統合されていて、
 過去の履歴を
 永続データとして持つ
 分析用データベースのことである。