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

data_warahouse

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

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

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

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

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

まとめ:DWHの4つの特徴

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

AWS Cloud Roadshow 2017 福岡