データの仕事をずっとやってるけど今更読み始めたのでメモ
Ralph Kimball 著の The Data Warehouse Tookit 3rd Edition を米尼から購入。
ETL Toolkit と Lifecycle Toolkit との3点セットで USD $113 プラス送料で安かった。
水曜に頼んだら金曜の夜に届いた。早い。Amazon が早いというか UPS とクロネコヤマトがすごいのかｗ
という訳で読み進めつつメモを書いていく。
ディメンショナル・モデリング
Wikipedia の Data warehaouse の項にかいてあるんだが、データウェアハウスのモデルは主にディメンショナルモデルと、第3正規形モデルに分かれる。
ディメンショナルモデルはどんなものかと言うと、トランザクションデータ、主に数値指標やアクションのデータが含まれるファクトテーブルと、そのファクトに対する説明や内訳にあたる日付や製品名、メーカーや顧客情報などを詳細な内訳・説明を含むディメンションテーブルに分けるモデルを言う。
ファクトテーブルを中心にディメンションテーブルがスター型スキーマになるのが特徴。
スター型スキーマなんだけど、ディメンションが増えるとムカデ型になる(謎
色々気をつけるべき点があって一度には覚えられんので都度メモる。
ディメンショナル・モデルを構築する4つのステップ
ファクトとディメンションに分けるにあたり、必ずこの4つのステップを踏む。
Step 1: ビジネス・プロセスを選ぶ
ビジネス・プロセスというのは組織におけるアクションであり「動詞」で表現出来る。
- 注文する
- 請求する
- 支払う
- 問い合わせ電話を受ける
- 支払いを受け取る
- 申込みを受ける
などなどのアクション。
そしてこれらは数値指標でカウント出来るKPIである。
そして、ビジネス・プロセスで必要なのはKPIになるアクションであって、ビジネス戦略とか戦術とかプランではない。
Step 2: 粒度を決める
この粒度というのはDBの行の事。
つまり、ファクトテーブルの「1行」が何を意味するのかを決める。
- 受注トランザクション毎に1行
- 販売商品のSKUごとに1行
- 空港の搭乗ゲートで搭乗券を1回スキャンするごとに1行
- 銀行口座1件を毎月ごとに1行
などなどのビジネス・プロセスにおけるイベントを表す1行の定義。
業務における専門用語で表現される事が多い。
トランザクションIDとかSKU、まさにファクトテーブルの「1行」になるものが存在してる。
この「1行の定義」は重要で、この次に書くけどリテールだとトランザクションID毎に1行じゃなくてSKU毎に1行にしてる。
どれが正しいかは要件次第である。
Step 3: ディメンションを定義する
日付・製品・メーカー・各補足情報などがディメンション
ここは思いつく限り詳細な内訳・説明を出来るものにする必要がある。
- who
- what
- where
- when
- why
- how
各指標に対して、これらの問いに答えられる情報で構成する。
そしてこのディメンションは変わる事がある、たとえば顧客の住所とか。
このように変わる可能性があるディメンションを Slowly-Changing-Dimensions と言って、上書きするか追記するか決める必要がある。
上書きする事を Type1 型と言って、追記を Type2 型と言う。
で、顧客住所など変更履歴が必要なディメンションは Type2 型が望ましい。
実装方法は詳しくは今後学ぶけど、Type2 型にするなら3つの追加カラムが必要。
- 開始タイムスタンプ
- 終了タイムスタンプ
- 現在の値である事を示すフラグ
Type7 まであるんだけどよく使うのは1か2だ。
Step 4: ファクトを定義する
これはまさにビジネス指標そのもの。
数値でカウント出来るものであり、例えば受注件数と受注金額などで表される。
ビジネス要件と実際のデータ両方のインプットから構成される。
という訳で、ディメンショナル・モデリングを行うデータエンジニアは半分データエンジニアであって半分ビジネスコンサルタントでもある事が求められるって事だな。
つづく。