Data Vaultモデリング入門（DV1.0/DV2.0）：歴史・構造・メリデメ・Snowflakeとの相性まで

🚀 はじめに：前回の俯瞰記事の続編として、Data Vaultを「理解して説明できる」ところまで整理する

前回の記事では、データモデリングの手法と歴史、DB製品の流行を「なぜそう進化したのか」という観点で俯瞰しました。
その中で DWH統合のための設計パターン として Data Vault（データ・ボールト）に触れましたが、実務に落とそうとすると疑問が一気に増えます。

• 「Data Vaultって、スタースキーマ（星型）と何が違うの？」
• 「DV1.0とDV2.0の違いは？どこまでやればDV2.0？」
• 「メリットはわかるけど、どんなデメリット・コストがある？」
• 「Snowflakeだと相性が良いと言われるけど、どこが噛み合う？」

この記事は、上の疑問に答える形で、Data Vaultを 初学者向けに体系立てて まとめたものです。

• 前回記事（データモデリングの手法と歴史、DB製品の流行を一気に俯瞰する）：https://zenn.dev/yujmatsu/articles/20251220_data_modeling

この記事でわかること

• Data Vaultが生まれた背景（Inmon vs Kimballの文脈）
• Data Vault 1.0 → 2.0 の進化ポイント（「モデル」→「方法論＋実装標準」）
• Hub / Link / Satellite（H/L/S）の役割と、設計の勘所
• Stage / Raw Vault / Business Vault / Mart の責務分離
• PIT / Bridgeなど「使いやすさ・性能」を担保する補助構造
• 採用判断の材料（メリット/デメリット、向き/不向き）
• SnowflakeとData Vaultが噛み合う理由（機能と紐づけて説明）

0. まず先に：Data Vaultが「向くケース / 向かないケース」

Data Vaultは強力ですが、万能ではありません。まずは“向く/向かない”を整理しておくと迷いが減ります。

向くケース（刺さりやすい）

• データソースが多い / 増え続ける（CRM、ERP、SaaS、ログ…）
• M&Aやシステム刷新が多い（旧システムと新システムの併存期間が長い）
• 監査・説明責任が重い（いつ・どこから来た値かを説明したい）
• 将来の用途が読めないが、まず統合して履歴ごと貯めたい
• チームが自動化（dbt等）を前提にできる（テンプレ化・標準化に投資できる）

向かない（または慎重に検討すべき）ケース

• ソースが少なく、要件が安定している（まずは星型で十分なことが多い）
• BI用途だけが目的で、履歴・監査・統合の要求が薄い
• 運用ガバナンス（命名規約・メタデータ管理・自動化）に投資できない

大事なポイント：
Data Vaultは「BIを便利にするモデル」ではなく、まず「統合・履歴・監査の土台」を作るモデルです。
BIの使いやすさ（スタースキーマなど）は 下流のマート層で作るのが基本です。

図1：Data Vaultの全体像（Stage → Raw Vault → Business Vault → Mart）

1. Data Vaultとは何か（スタースキーマと“役割”が違う）

Data Vault（データ・ボールト）は、DWHの中で 「統合・履歴・監査」を最優先して設計するモデリング手法です。

分析でよく使う スタースキーマ（ファクト＋ディメンション） と比べると、

• スタースキーマ：分析しやすい形（理解しやすい・速い）を優先する
• Data Vault：統合しやすい形（変化に強い・履歴を残す・監査に強い）を優先する

という違いがあります。

2. なぜData Vaultが生まれたのか（Inmon vs Kimballの文脈）

DWHの世界には、よく「Inmon派 vs Kimball派」という二大潮流があります。

• Inmon：企業全体の統合DWHを正規化（3NF）で作り、そこから用途別マートを作る
• Kimball：分析しやすいスタースキーマ中心のマートを積み上げる

どちらにも強みがありますが、2000年代以降は

• データソース増加
• ビジネス変更の高速化
• 監査・コンプライアンス要求の増加

などで、従来のどちらか“だけ”では辛い場面が増えました。

そこで 「統合は強く、変更に強く、履歴と出所を残す」 ことに重心を置いた設計として、Data Vaultが注目されるようになります。

図2：Inmon / Kimball / Data Vault の比較

3. 歴史とバージョン変遷：DV1.0 → DV2.0

3.1 Data Vaultの起点（よくある誤解も含めて）

Data Vault は Dan Linstedt によって提唱された手法です。

「2000年頃に登場」と一言で紹介されることも多いですが、資料では 1990年代初頭に研究が始まり、1999年頃にアプローチが形になり、1999〜2001年にテスト/改良/導入が進み、2003年に公開講座が始まった という流れが説明されています。
（参考：Kent Graziano / Dan Linstedt Introduction to Data Vault Modeling）

3.2 DV1.0：モデル（H/L/S）の骨格を確立

DV1.0の中核は、次の3種類のテーブルに分けることです。

• Hub：不変の識別子（ビジネスキー）
• Link：関係
• Satellite：属性＋履歴

これにより、属性追加や関係の変化が起きても、既存モデルに大きな破壊を起こしにくくします。

3.3 DV2.0（2010年代前半〜）：モデル＋方法論＋実装標準へ

DV2.0は、単なるモデル定義だけでなく、方法論（アジャイル開発・品質管理）や、クラウド/MPP前提の実装パターンまで含む“包括的な標準”として整理されます。

よく挙げられる進化ポイントは以下です（※すべてが必須というより、プロジェクト特性に応じて採用されます）。

• ハッシュキー（Hash Key）を前提にした実装パターン（推奨されることが多い）
  → 固定長キー化により分散/並列ロードや結合を扱いやすくする
• Hash Diff を使った変更検出（Satellite差分ロード）
• Raw Vault と Business Vault の責務分離の明確化
• ビッグデータ/半構造化データなど、現代的データ源を前提に含める
• 自動化（テンプレ化/標準化）を前提にスケールさせる

図3：DV1.0→DV2.0の進化ポイント

4. 基本構造：Hub / Link / Satellite（H/L/S）

ここがData Vaultのコアです。初学者はまずこの3つを押さえると理解が進みます。

4.1 Hub（ハブ）：ビジネスキーの“台帳”

Hubは ビジネスキー（業務上の識別子） を格納するテーブルです。
例：顧客ID、商品コード、口座番号、従業員番号など。

Hubは「存在の登録簿」なので、基本的に属性（氏名、住所など）は持ちません。
また、監査のために「いつ入ったか（LOAD_DTS）」「どこから来たか（RECORD_SOURCE）」を持たせます。

4.2 Link（リンク）：Hub同士の“関係”

Linkは Hub同士の関係を表します。

例：

• 顧客が注文した（Customer–Order）
• 注文に商品が含まれる（Order–Product）

関係をテーブルとして独立させることで、将来「関係が多対多に変わる」「関係の粒度が変わる」などの変化に強くします。

4.3 Satellite（サテライト）：属性と履歴（変化する情報）

Satelliteは、HubやLinkにぶら下がる 属性（説明情報） を履歴付きで保持します。

• 顧客の氏名・住所・会員ランク
• 注文の状態・金額・配送情報
• 関係（Link）そのものの属性（配属日、契約開始日など）

Data Vaultでは「履歴が価値」なので、Satelliteは 追記（insert-only） で履歴を積み上げる設計がよく採用されます。

図4：Hub/Link/Satelliteの具体例（顧客・注文・明細）

5. レイヤー構成：Stage → Raw Vault → Business Vault → Mart

Data Vaultを“運用できる設計”にするには、層の責務分離が重要です。

5.1 Stage（PSA）：取り込みの整合点

• ソースから届いたデータをまず受ける
• 型やフォーマットなど、格納に必要な最小限の調整をする
• 再処理の起点になる（「もう一度やり直せる」場所）

※ PSA は Persistent Staging Area を指します。プロジェクトによっては「Landing」や「Bronze」に相当する層として扱われます。

5.2 Raw Vault：監査可能な“事実保管庫”

Raw Vaultの狙いはシンプルです。

• ソースから来た事実を、監査可能に、履歴付きで残す
• 後から「なぜこの数値になった？」を辿れるようにする

そのため、ここでは「ビジネスルールによる強い加工」をやりすぎないのが基本方針になります。

5.3 Business Vault：ビジネスルール適用＆高速化

Business Vaultでは、Raw Vaultを元に“使える形”へ寄せます。

• 名寄せ、重複排除、派生計算（粗利など）
• PIT/Bridgeなどのクエリ補助構造
• 組織としての定義（例：ゴールデンレコード）

5.4 Mart：利用者向け（BI/分析）

最終的にユーザーが使う形に整える層です。

• スタースキーマ（Fact/Dim）
• ワイドテーブル
• あるいは Snowflake の性能を前提に View で仮想化する、など

図5：Snowflake上のData Vaultレイヤー配置（例）

6. DV2.0でよく出る実装パターン（初学者が押さえるべき勘所）

ここは「実装に入った時に詰まりやすいポイント」を中心に。

6.1 ビジネスキー定義が最重要

Data Vaultは「ビジネスキーの統合」が軸です。
ここが曖昧だと、どんなにきれいなH/L/Sを作っても、統合が破綻します。

• 「顧客」とは何か？（個人？法人？契約単位？）
• 同一人物の判定（名寄せ）を Raw でやるのか Business でやるのか？
• システムごとにキーが違う場合どうするか？

おすすめの整理：

• Raw Vault：ソースの事実を壊さずに保管する
• Business Vault：統合ルールを適用して“組織の定義”を作る

こうすると、統合ルールが変わっても Raw から再構成できます。

6.2 Satelliteは分割する（ソース別／変化率別／機密別）

Satelliteは「全部1つに詰める」と運用が辛くなります。
よくある分割軸は次の3つです。

• ソース別（監査やリネージが明確になる）
• 変化率別（頻繁に変わる属性と、ほぼ変わらない属性を分ける）
• 機密別（PIIや機微情報を隔離し、権限/マスキング設計をしやすくする）

6.3 Hash Key / Hash Diff（DV2.0の“らしさ”）

DV2.0では、キーや変更検出にハッシュ関数を用いる実装が一般的です。

• Hash Key：ビジネスキー（または複合キー）をハッシュして固定長キーにする
• Hash Diff：Satelliteの属性群をハッシュして、前回から変更があるか判定する

Snowflakeには MD5_BINARY や SHA2_BINARY などの関数があり、DV2.0実装でよく利用されます。
なお Snowflake のドキュメントでは、MD5は暗号用途ではなくチェックサム等の用途が想定である旨が明記されています（DVのキー用途は“暗号化”とは別の話ですが、誤解しやすいので注意点として押さえると良いです）。

• MD5_BINARY：https://docs.snowflake.com/en/sql-reference/functions/md5_binary
• SHA2_BINARY：https://docs.snowflake.com/en/sql-reference/functions/sha2_binary

重要：ハッシュの入力正規化（trim/大小文字/null/区切り文字の扱い）が崩れると、同じビジネスキーでも別物扱いになり統合できなくなります。
ハッシュ生成ルールはチームで標準化しましょう。

6.4 Insert-only と「仮想的な終端日」

Satelliteは更新（UPDATE）ではなく、追記（INSERT）で履歴を積む設計がよく採用されます。

• 履歴が自然に残る（監査に強い）
• 変更検出（Hash Diff）で“変わった時だけ挿入”にできる

終端日（end date）については、物理的に持たずに ウィンドウ関数やビューで仮想的に計算 する設計がよく見られます（「いつまで有効だったか」を後から導出する）。

7. PIT/Bridge：Data Vaultを「使いやすく」「速く」する補助構造

Data Vaultの弱点としてよく挙がるのが JOINが増えやすいことです。
そこでBusiness Vault層に、クエリ補助の構造を作ります。

7.1 PIT（Point-In-Time）テーブル

課題：複数Satelliteの「ある時点の最新行」を取るのは、毎回やると複雑で遅い

PITテーブルは、あらかじめ「時点ごとの参照先」をまとめておくことで、

• クエリを単純化し
• 等価結合中心にして高速化する
  ことを狙います。

7.2 Bridge（ブリッジ）テーブル

Bridgeは、よく使うLinkの結合パス（関係の道筋）を事前にフラット化しておく構造です。

• 多段の結合を短縮する
• マート作成を簡単にする

図6：PIT/Bridgeの役割（Before/After）

8. メリット・デメリット（採用判断の材料）

8.1 メリット

• 変更に強い：新しい属性＝Satellite追加、新しい関係＝Link追加で吸収しやすい
• 監査・トレーサビリティ：ロード日時/出所を標準で持てるため説明責任を担保しやすい
• 履歴を標準形で保持しやすい：後から別解釈で再構成できる
• 並列ロード・自動化と相性が良い：構造がパターン化されるためテンプレ化しやすい

8.2 デメリット

• テーブル数が増える（管理が難しい）：命名規約とメタデータ管理が必須
• Raw Vaultを直接使うのは難しい：Business VaultやMartが前提（工数増）
• 学習コスト：Linkの粒度設計、Satellite分割、履歴設計などに慣れが必要
• 自動化がほぼ必須：手作業だとスケールしない（dbt等の導入が現実的）

9. Snowflakeとの親和性：どこが噛み合うのか

Data Vaultは「テーブル数が多い」「JOINが多い」「履歴でデータ量が増える」「増分運用が前提」になりがちです。
Snowflakeは、これらの性質と噛み合う機能を多く持っています（ただし キー定義・命名規約・自動化 が前提です）。

9.1 Micro-partitions とクエリプルーニング（“読まない最適化”）

Snowflakeはデータをマイクロパーティションとして管理し、メタデータを使ってクエリ実行時に不要なパーティションを読み飛ばす（プルーニング）仕組みを持ちます。
Data Vaultはキーや日時で絞るクエリが多いため、この仕組みの恩恵を受けやすいです。

• 参考（Snowflake docs）：https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions

9.2 Multi-table INSERT（Hub/Link/Satへの振り分け）

Data Vaultのロードでは「同じ入力データから、Hub/Link/Satelliteへ振り分けて挿入」という処理がよく出ます。
Snowflakeは multi-table INSERT を提供しており、1回の入力スキャンで複数テーブルへ挿入できます。

• Snowflake docs：https://docs.snowflake.com/en/sql-reference/sql/insert-multi-table
• Snowflake blog（Data Vaultでの使いどころ整理）：https://www.snowflake.com/en/blog/data-vault-techniques-conditional-multi-table-insert/

9.3 Streams & Tasks（差分検知とスケジューリング）

Snowflakeの Streams は、テーブル等の変更差分（CDC）を追跡します。
Tasks はスケジュール実行（または依存関係に基づく実行）に使えます。
増分ロード中心のData Vault運用と相性が良い機能です。

• Streams intro：https://docs.snowflake.com/en/user-guide/streams-intro
• Streams & Tasks intro：https://docs.snowflake.com/en/user-guide/data-pipelines-intro

9.4 Dynamic Tables（派生層の運用を宣言的に）

Snowflakeの Dynamic Tables は、定義したクエリ結果をテーブルとして維持し、増分更新を自動管理する仕組みです。
PITなどの派生層の運用を簡素化できる可能性があり、SnowflakeのブログでもData Vaultとの組み合わせが紹介されています。

• Snowflake blog：https://www.snowflake.com/en/blog/dynamic-tables-data-vault/

9.5 VARIANT（半構造化データの受け皿）

Data Vaultでは「まずはソースの事実を壊さず受ける」が基本方針になるため、半構造化（JSONなど）を“そのまま持つ”ケースが増えます。
Snowflakeの VARIANT 型はこの用途に向きます。

9.6 Zero-copy clone（本番相当データで検証しやすい）

Data Vaultは「モデル追加」や「パイプライン変更」が多いので、本番相当データで検証したい場面が多いです。
Snowflakeは CREATE … CLONE によるゼロコピークローンで、DB/スキーマ/テーブルを高速に複製できます。

• Snowflake docs：https://docs.snowflake.com/en/sql-reference/sql/create-clone

図7：Snowflake機能×Data Vault課題の対応（概念図）

10. ユースケース（汎用パターン＋業種別の例）

汎用パターン

• 多ソース統合（CRM/ERP/EC/広告/コールセンター…）
• M&Aや基幹刷新で旧新が併存する
• 監査・説明責任が強い
• 将来の分析用途が読めないので“まず貯めたい”

業種別の例

• 金融（銀行・証券・保険）：契約/取引の履歴、監査証跡、規制対応
• 小売・EC：会員/注文/在庫/物流/広告など多ソースで粒度が揺れやすい
• 製造・IoT：設備/BOM/稼働ログ/品質データなど関係が多層、履歴も重要
• 医療・ヘルスケア：真正性・監査・履歴が強い、システムも多い
• 通信：契約/回線/料金/利用ログなど巨大データで関係が複雑

11. 初学者向け：導入の進め方（失敗しにくい順序）

1. 採用理由を明文化（統合？履歴？監査？）
2. スモールスタート（1〜2ドメインでStage→Raw→Business→Martまで通す）
3. ビジネスキー定義を固める（最重要）
4. 命名規約・標準カラムを統一（LOAD_DTS、RECORD_SOURCE等）
5. 自動化を前提にする（dbt/AutomateDVなど）
6. Raw Vault直BIを避ける（Business/Martで提供）

12. よくある落とし穴（短く）

• 小規模・単一ソースに当てて“過剰設計”になる
• マートを作らず Raw Vault を直接使わせて利用が進まない
• 命名規約が崩れてどこに何があるかわからなくなる
• ハッシュ入力の正規化を軽視して統合できなくなる
• 自動化なしで運用しようとして破綻する

😌 まとめ

• Data Vaultは「統合・履歴・監査」を強くするDWH向けモデリング
• DV2.0はモデルだけでなく、クラウド/並列/自動化前提の実装標準まで含む
• Raw Vaultに事実を残し、Business VaultとMartで 使える形 にするのが基本
• SnowflakeはData Vault運用の課題を吸収しやすい機能が多い（ただし設計とガバナンスは必須）

📚 参考リンク（深掘り用）

• Data vault modeling（概要・歴史）：https://en.wikipedia.org/wiki/Data_vault_modeling
• Introduction to Data Vault Modeling（背景・年表の説明）：https://kentgraziano.com/wp-content/uploads/2012/02/introduction-to-data-vault-modeling.pdf
• Snowflake docs：Micro-partitions & pruning：https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions
• Snowflake docs：INSERT (multi-table)：https://docs.snowflake.com/en/sql-reference/sql/insert-multi-table
• Snowflake docs：Streams intro：https://docs.snowflake.com/en/user-guide/streams-intro
• Snowflake blog：Dynamic Tables for Data Vault：https://www.snowflake.com/en/blog/dynamic-tables-data-vault/
• Snowflake blog：Conditional Multi-Table INSERT：https://www.snowflake.com/en/blog/data-vault-techniques-conditional-multi-table-insert/