Open1

The Data Vault Guru: A pragmatic guide on building a data vaultを読む

IsTre1592IsTre1592

Profiling data

  • Data Vaultモデリングを始める前にソースデータをよく理解するためのプロファイリングが重要とのこと
  • ビジネスキーや関係性、属性の特性、参照データ、テクニカルデットなどを洗い出す

以下はやること

  1. エンタープライズ論理データモデルを活用する
    • Hubテーブル命名規則をオンタロジー（概念体系）に基づいて整理するのに役立つ。
  2. ビジネスエンティティと、その不変で永続的なビジネスキー（Hub）を特定する
  • 可能ならば、連番の代替キー（サロゲートキー）は避ける。
  • 新しいHubを作るのか、それとも既存のHubにロードするのか？
  • 既存Hubのビジネスキーと競合しないか？ → 「business key collision codes（キー衝突コード）」を参照し、ガバナンスに従う。
  • ビジネスキーはマスタ化されているか？
  • ビジネスキーは一意に識別できるか？
  • キーはマスキングや匿名化が必要か？
  1. リレーションシップ（Link）を特定する
    • 単位（unit of work）を特定する。
    • 最小カーディナリティ（関係の最小数）を確認する。
  2. 記述的データと、その配置先（Satellite）を特定する
    • データの粒度（grain）はビジネスキーにどう対応しているか？
    • 子キー（dependent child keys）を特定する必要があるか？
    • 日内キー（intra-day batch keys）が必要か？
    • データは既に集計されているか？（未集計データを取得できないか？）
    • 記述データはビジネスエンティティを表すか、それとも関係を表すか？
    • 記述データの変化率（rate of change）は？（サテライト分割の候補）
    • 記述属性の中に個人識別可能情報（PII）は含まれるか？ → サテライト分割の候補。
  3. 参照データを特定する
    • ソースシステムに参照データテーブルはあるか？
    • 既にコードや定義を持っているか？新しいコードが必要か？
    • 参照データを「参照データ管理（RDM）」に統合できるか？
  4. 統合デット（Integration debt）を確認する
    • 例：ビジネスキー列が過負荷で、異なる意味を持つキーを1列に含めている場合
    • 解決策の優先順位：
      1. ソースシステムが適切な粒度で提供
      2. 前処理ステージで解決
      3. Business Vaultで解決
  5. 技術的負債／アプリケーションギャップを確認する
    • 派生情報が足りない場合など
    • 解決策の優先順位：
      1. ソースシステムで満たす
      2. 前処理ステージで解決
      3. Business Vaultで解決
  6. 複合ビジネスキー（Mashed business keys）を確認する
    • 例：1つの列に複数のキーを連結して格納している場合。
    • 解決策の優先順位：
      1. ソースシステムで分解して提供
      2. 前処理ステージで分解（データ品質やメンテナンスの課題あり）
      3. （最悪）そのまま → ただしHubテーブルにロードするには分解が必要
  7. アプリケーションデータと必要なデータの間にギャップがあるか？
    • Business Vault候補