前提
筆者のスペック
- SQLが書ける程度でデータベースに詳しいかと言われるとそうではない新卒1年目のエンジニア（の卵）。
- DWHとかデータウェアハウスって聞いたことあるけど具体的に何かはわからない。
- DWHに加えてデータマートとやらが必要らしいとは知っていたが、具体的にデータマートが何かわからない。
- DWHの4特性を知らなかった。
- もちろんDWHの3つのアーキテクチャを知らなかった。
- データベースよりむしろフロントエンドの方が好き。
今回の取り組みの目的
DWHの設計方法を理解し、要件に沿った最適な設計が可能になること。（2日で）
以上。
要件
複数のデータソースを元にBIツールでの分析がしたい。そのために必要なDWH・データマートを設計すること。
分析自体の要件は決まっているため、データソースを元にDWH・データマートをどのような設計にするか決定することがゴール。
データウェアハウス(DWH)とは
1990年、インモンが提唱。
基幹系データベースと、意思決定支援システムに用いられる情報系データベースとの分離を説き、提唱したシステム環境1
この定義じゃ難しいですね。。。
簡単に、「目的別に再構成した統合データベース」という理解で良いかと思います。
DWHの4特性
サブジェクト指向（subject oriented）
企業が必要とするテーマや目的、用途別のデータモデリング
データの統合（integrated）
データ項目の命名規則、単位、コード体系、データ形式などを統一した基準の下で行う
時系列（time variant）
ある時点の値を持つデータ（スナップショット）を時間的な順序で集めたもので構成される
不変性（non-volatile）
時系列のスナップショットは、DWHに一度正しく蓄積されると更新されることはない
DWHの3つのアーキテクチャ
色々と呼び名があるようですが、こちらの連載にある名称に統一します。
DWHと言えばこれ、のようなデファクトスタンダードなアーキテクチャはないみたいです。
コーポレートインフォメーションファクトリー
先ほども登場したインモンさんが提唱したアーキテクチャです。そのため、インモンモデルとも呼ばれます。
エンタープライズデータウェアハウスという企業のすべてのデータを集めたセントラルデータベースを構築し、そこから各部署で分析に必要なデータをデータマートとして、抽出、構築して分析はそのデータマートに対して分析を行うというものです。2
エンタープライズデータウェアハウスは第3正規形で構築、データマートは非正規化し、分析に適したスタースキーマを構築することでクエリパフォーマンスをアップするという思想のようです。
キンボールディメンショナルデータウェアハウス
ラルフ・キンボールさんが提唱したアーキテクチャです。キンボールモデルとも呼ばれます。
ディメンショナルデータウェアハウスアーキテクチャですが、これは簡単にいってしまえば、ディメンショナルモデリング、つまり、スタースキーマでデータウェアハウスを構築することです。3
データウェアハウスはスタースキーマを持ったデータマートの集合だ、という思想のようです。
データボルトモデリング
すべてのオペレーションシステムから来たデータをそのまま保管するモデリング4
・・・？
仕様変化に耐えうる、万が一のことに対応できるなどの利点があるようですが、今回目指すBIツールによる分析という要件からは大きく外れるため早々に却下しました。
スタースキーマ
第5回：ディメンショナルモデリング：スタースキーマやスター スキーマによるデータ ウェアハウス設計などの良い解説記事があるため、詳しくは解説せず特徴を述べるだけにします。
特徴
ファクトテーブル
スタースキーマの中心となるテーブルで、特定のイベントを記述する情報が含まれ、主要なデータを持つ。
各ディメンションテーブルの外部キーとなるカラムを持つ。
ディメンションテーブル
ファクトテーブル内の情報を記述するデータを保存している。マスターデータのイメージ。
クエリの単純化のため、第2正規形に留めておくことが一般的。
注意点
ファクト同士、マスタ同士が結合してはいけない。
→クエリのパフォーマンス低下につながるため。
検討事項
DWHについて一通り調べたところで、要件を念頭に置きつつDWH&データマートの設計を考えています。
画面側のレスポンスを早くするために簡単なクエリで集計できるデータマートが必要になるので、主にそこについて考えています。
画面側の要件も読み解きつつやるしかないですねー。
参考書籍
10年戦えるデータ分析入門
第11章のDWHに関する記述が役に立ちました。