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

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

1.1. OLTP vs DW/BI：2 つの異なる世界

• OLTP：「実行」業務プロセスで用いられるデータ処理の考え方

• DWH：「評価」データ分析側からのクエリパフォーマンスを重視する考え方

  基準	OLTP (オンライントランザクション処理)	DWH (データウェアハウス)
  目的	個々のビジネスプロセスの評価	複数のビジネスプロセスの評価
  頻度	リアルタイム	定期実行
  適したモデリング	ER (Entity-Relationship)	ディメンショナル
  モデル図	ER 図	スタースキーマ
  利点	冗長化 (第 3 正規化) されており、トランザクションが効率的	ファクトに対して必要なテーブル・結合関係がわかりやすい
  欠点	テーブル・結合関係が複雑でクエリ効率が悪い

• ディメンショナルモデリング：ビジネスプロセスと個々の事象をファクトとディメンション（＝ファクト中の個々の指標）で定義。ディメンションを個々のテーブルからの結合で取り出し処理。スタースキーマで図式化される。

  • ファクト（指標）：評価したいデータテーブル
  • ディメンション（説明）：ファクトを説明するカラムが存在する関連テーブル
  • スタースキーマ：ファクトを中心にディメンションを結合して構築されるモデルのこと。データキューブでも 3 次元以下ならば説明できるが、4次元以上では、スタースキーマの方が簡潔に説明可能。

引用：https://blog.flinters-base.co.jp/entry/2022/09/28/000000

• 7 W (Who, What, When, Where, HoW many, Why, HoW) でビジネスイベントの詳細を説明することでビジネスプロセス測定の必要性や測定方法の観点でモデリングを効率的にできる
• スタースキーマにより、アジャイル原則に基づいた迅速かつ継続的な開発が可能。

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

• 従来型の分析軸

  手法	データ駆動型分析	レポート駆動型分析
  考え方	データソースの分析から要件を決定	レポートからデータ要件を決定
  デメリット	ユーザーの意見を聞かないので、ニーズに応えられない割に時間と費用がかかる。	ユーザー意見を聞き取るのに時間がかかり、短絡的な変更に終始してしまうことがある。

• 2000年付近と比較して、2010年以降の開発では、DWH 開発はプロアクティブにされるようになってきた

  • 利点：BI 側のデータに関する検討が容易になる
  • 欠点：データ後発なので、BI の要件収集をデータ利用可能になる前に集める必要があり、従来型の分析軸では難しい → アジャイルなDWH 設計が必要

• アジャイルな DWH 設計：反復的・段階的・協調的なアプローチによって先行分析に対するリスク低減を可能に

• アジャイルなデータモデリング：反復的・協調的なデータモデリング

  • 反復的：既存の要件を理解し。リファクタリングしていくこと
  • 協調的：ステークホルダーと一緒にデータモデリングを進めること

  「必要なものを必要な時に必要なだけ」「先手を打ったちょうど良い設計」

1.3. BEAM＊

• Business Event Analysis & Modeling, アジャイルなデータモデリング手法の一つ

• 7 W に基づいた質問をモデリングする側がステークホルダーにして、データストーリーを記述してもらう

• BEAM＊テーブル：データストーリーを表形式に記述し、サンプルデータを当てはめてデータ要件の洗い出しを行うレポート

  顧客は	製品を注文する	注文日に	数量	売上高で	割引で	注文IDを使って
  [Who]	[What] MD, GD	[When] MD	[HoW many]	[HoW many]	[HoW]	[HoW] GD

  ↑のように抽象的なディメンショナル属性を具体的なデータと共に表記しておくことで、ステークホルダー側のデータ処理に対する理解を促進する役割がある

  ※ ショートコード：MD, GD などのディメンション固有属性の略記方法