Data Vaultモデリングの手順：Hub・Link・Satelliteを業務にどう当てはめるか

Data Vault 2.0の入門記事を読み終えて、いざ自社のデータに当てはめようとすると、最初の一歩で詰まりがちです。「顧客はHubでいいとして、配送先住所はSatellite？それともLinkを介して別Hub？」「商品コードが変わったらどうする？」具体に降ろすと、判断ポイントが急に増えます。

小さなECサイトを題材に、Data Vaultでモデリングする手順を5ステップで実演します。考え方を業務に当てはめる勘どころと、dbtでの実装イメージを並べます。

題材：小さなECサイトの業務

題材として、シンプルなECサイトを想定します。実際の業務はもっと複雑ですが、判断ポイントを押さえるには十分です。

• 顧客は会員登録し、メールアドレスを持つ
• 商品は商品コードで管理され、価格は変動する
• 注文は1人の顧客が複数商品を1回で買う単位
• 配送先は注文ごとに指定でき、自宅以外も選べる

ステップ1：ビジネス概念を洗い出してHubにする

最初に、業務に登場する「概念」を抜き出します。Hubの候補です。判断基準は「業務上、独立して存在意義がある名詞」かどうかです。

配送先住所のように、Hubにするか属性（Satellite）にするか迷う概念があります。判断基準は「他のHubから独立して参照する場面があるか」です。例えば、配送拠点の住所が複数の注文に共有される業務なら独立Hub、注文のたびに自由入力されて再利用しない業務ならSatelliteに留めます。今回は再利用しない前提で、Satelliteで扱います。

ステップ2：Hub同士の関係をLinkで結ぶ

次に、Hub同士の関係を洗い出します。Linkの候補です。

Linkは「関係の存在」を記録します。明細行の数量や単価といった属性は、Linkに直接持たせず、別のSatelliteに分けて持ちます。「Linkは関係そのもの、属性はSatellite」と覚えると、ぶれません。

ステップ3：属性と履歴をSatelliteに分ける

属性は、HubやLinkに紐づくSatelliteに集めます。ここでひと工夫したいのが、属性のグルーピングです。1つのHubに対して、Satelliteは複数持てます。グルーピングの軸は次の3つです。

• 変更頻度：頻繁に変わる属性と、ほぼ変わらない属性を分ける（差分検知の効率が上がる）
• ソースシステム：基幹システムとCRMで同じ顧客の異なる属性を持つなら、Satelliteを分けてソース別に管理
• 機密度：公開可能な情報と機密情報を分けて、アクセス制御をかけやすくする

例えば顧客HUBに対して、次のようにSatelliteを分けるパターンがあります。

ステップ4：dbtで実装する

dbtを使えば、Data VaultのHub・Link・Satelliteをパッケージのマクロで書けます。代表的なのがAutomateDV（旧dbtvault）です。素のSQLで書く例も先に置きます。

-- 素のSQLでHubを実装する例（dbtモデル）
-- models/silver/hub_customer.sql
{{ config(materialized='incremental', unique_key='hub_customer_hk') }}

SELECT DISTINCT
  MD5(customer_id)        AS hub_customer_hk,
  customer_id             AS customer_bk,
  CURRENT_TIMESTAMP()     AS load_date,
  'ec_main'               AS record_source
FROM {{ ref('stg_customer') }}
{% if is_incremental() %}
WHERE MD5(customer_id) NOT IN (SELECT hub_customer_hk FROM {{ this }})
{% endif %}

-- AutomateDVマクロを使った場合の同等の記述
-- models/silver/hub_customer.sql
{{ config(materialized='incremental') }}
{{ automate_dv.hub(
    src_pk='hub_customer_hk',
    src_nk='customer_bk',
    src_ldts='load_date',
    src_source='record_source',
    source_model='stg_customer'
) }}

Satelliteは、差分検知用のhash_diff（属性をハッシュ化したもの）を計算し、前回観測時から値が変わっていれば新しい行を追加する、という形になります。dbtの階層化された変換の延長として実装でき、メダリオンのSilver層で動かすのが自然です。

ステップ5：Gold層のマートを別途用意する

Data Vaultで作った統合層は、BIから叩くには重いです。Gold層に、用途別のマートを別途用意します。

Gold層では、Data Vaultの履歴を「最新値だけ」「過去全部」「特定時点」と用途に応じて切り出します。BIから見ると、シンプルなスタースキーマやワイドテーブルが並ぶだけで、Data Vaultの複雑さは下に隠れます。

よくある設計の落とし穴

導入チームでよく見る間違いを挙げます。

• HubのキーをサロゲートIDにする：1.0時代の設計です。2.0はビジネスキーのハッシュを使うのが原則です（並列ロードのため）。
• LinkのSatelliteを忘れる：明細行の数量・単価などはLinkに直書きせず、Linkに紐づくSatellite（SAT_ORDER_LINE_QTY）に分けます。
• Satelliteを1つにまとめすぎる：全属性を1つのSatelliteに詰めると、変更頻度の差を活かせず、機密度の分離もできません。
• Gold層を作らない：BIから直接Vaultを叩いて「重い」と評価される、典型的な失敗。

まとめ

• Hubは「業務上独立した概念」を切り出す。属性は持たない。
• Linkは「関係の存在」だけ。明細の属性はLinkに紐づくSatelliteへ。
• Satelliteは変更頻度・ソース・機密度で分けて持つと運用が楽。
• dbtで書くなら、AutomateDVのマクロでボイラープレートを削減。
• Gold層のマートは別途用意。BIはGoldを参照する。

全体像と背景はData Vault 2.0 入門、スタースキーマとの使い分けはData Vault と スタースキーマの判断軸、Snowflakeでの実装はData Vault on Snowflakeにまとめています。設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. HubとSatelliteの線引きで迷ったら、どう決めますか？

A. 判断基準は「他のHubから独立して参照する場面があるか」です。配送先住所のように、複数の注文や顧客から共有して参照する業務なら独立Hub、注文ごとに自由入力で再利用しないならSatelliteにします。迷ったら最初はSatelliteで作り、再利用が増えてからHubに昇格させるのが安全です。後からHubに分離するほうが、最初からHub過多で作るより手戻りが少なくなります。

Q. SatelliteのHash_diffはどう計算しますか？

A. 属性カラムを決まった順序で連結し、MD5やSHA-1でハッシュ化します。差分検知はこの値を前回の値と比較して、違えば新しい行を追加する、という流れです。dbtのAutomateDVを使えばマクロが標準で計算してくれます。順序を変えるとハッシュが変わるので、設計時に順序を固定するルールを決めておくと運用が安定します。

Q. PIT（Point-in-Time）テーブルやBridgeテーブルは必須ですか？

A. 必須ではありませんが、Gold層への変換を速くするために導入されます。PITはある時点の状態をスナップショットしたテーブル、Bridgeは複数Hub・Linkを結ぶ中間テーブルです。Vault側のJOIN数が増えてGold変換が重くなってきたタイミングで、最適化として後から導入するのが一般的です。最初は無しで始め、計測してから足してください。

Q. dbtのAutomateDVを使うべきですか、素のSQLで書くべきですか？

A. 中規模以上ならAutomateDVを推奨します。Hub・Link・Satelliteのテンプレ化、hash_diffの計算、差分検知のロジックを標準化でき、ボイラープレートが大幅に減ります。素のSQLは学習目的では有用ですが、本番運用ではDRY原則が破られ、保守が重くなります。Data Vaultは「同じパターンを多数並べる」モデリングなので、マクロ化の恩恵が大きい領域です。