『アジャイルデータモデリング』

第１章：データウェアハウスのモデリング方法

【要約】

1. OLTP vs DW/BI

• ERモデリング
• ディメンショナルモデリング
  • プロセス指向（7W）
    • プロセス単位でアジャイルに開発を進められる

2. データウェアハウスの分析と設計

• データ駆動型開発
  • 単一の『完璧な』第３正規形のモデルを設計
  • 業務システムが複雑化するにつれて対応が困難になる
• レポート駆動型開発
  • ディメンショナルモデリング
  • 現在のレポートのニーズだけに留まらないように「基礎となるビジネスプロセス」を発見することが重要
• アジャイルなデータウェアハウス設計
  • イテレーション
    • データモデリング
    • ETL
    • BI
    • レビュー
    • リリース
  • 利点
    • 協調的
    • インクリメンタル
    • 反復的

3. BEAM

• アジャイルなデータモデリングをサポートするツール
• ステークホルダーからも構造が分かりやすくなる

【所感】

1. OLTP vs DW/BI

• ディメンショナルモデリングの特徴と使い所が分かりやすい
• データエンジニアになる前に、ビッグデータサービスのバックエンド開発をしてたので、その時から（名前も知らず）ディメンショナルモデリングを使ってることが多かった
• データエンジニアになってディメンショナルモデリングを知った時も、目新しさを感じなかったのはそういう理由だったのか
• オペレーション業務に沿った（ドメインで駆動できるような）システムであれば、自ずと正規化されたモデリングになっていくのは、確かにそう思う

2. データウェアハウスの分析と設計

• プロアクティブなDW/BI開発が行われるのは、データ活用（実態や環境というより意識）が成熟した組織だろうな
• アジャイルの利点として、ステークホルダーに継続的に関わってもらい、継続的に関心を抱いてもらう（自発的に要求を引き出し続ける）という利点も大きい！使われないダッシュボード問題にも関わってくる！

第２章：ビジネスイベントのモデリング

【要約】

1. データストーリー

• ビジネスイベント
  • 離散型
  • 発展型
  • 反復型

2. BEAMの実践

• 7Wをヒアリングによりまとめる

【所感】

1. データストーリー

• このイベントがどの型に含まれるかを考えるだけで、適切なモデリングができそう。

2. BEAMの実践

• 当たり前だけど漏れをなくすためにフレームワーク大切
• ステークホルダーも聞かなきゃ答えないし、漏れなく聞くために7Wをまとめる
• 「非現実的な期待を抱かせない」は大事

第３章：ビジネスディメンションのモデリング

【要約】

• BEAMからディメンションのモデリング方法
  • ディメンションの切り出し方

【所感】

• ディメンション階層
  • 「そんな粒度で集計したかったのか！」とこれまで落とし穴になるケースが多かった
  • そして1番は組織ね。組織変更の柔軟性を持たせておかないと、通達が出るたびに考える必要がある
• ディメンション履歴
  • これも組織ね。期の途中での異動でどのように集計するかを毎回ヒアリングしなければいけないからなぁ
• 総じて、大事だけどここまでちゃんと事前に定義できないよな〜、でもしないから手戻り起こるんだよな〜

第４章：ビジネスプロセスのモデリング

【要約】

1. 複数イベントのアジャイルなモデリング

• 通常のビジネスでは複数のイベントが存在する
• 適合ディメンションにより複数イベントを結合して分析できるようにする
  • 適合ディメンション：複数のファクトテーブルで共有されているディメンション

【所感】

• 1人で考えが及ぶ範囲だと当然考慮することであっても、扱う範囲が増えたり、チームが増えたりした際に、このように共通となる資料があると、アナリティクスエンジニアのビジネス理解も早くなるよな

第５章：スタースキーマ

【要約】

• データプロファイリング
  • 欠損値
  • 一意な値と頻度
  • データの範囲と長さ

【所感】

• 加えてデータラングリングが必要
  • 自分から原因を解消しにいくプロセスはいつまでも必要
  • この役割を渡せる人がいたらいいんだが、、

• ひとまず１部は読み終えた。
• ２部はより細かくなるみたで、今のフェーズにToo Muchかなと思い、色々と進んだらで読み返そう