多くのデータベース設計者は、まず正規化されたリレーショナルモデル、あるいはディメンショナルモデル（スタースキーマ）をベースに設計を始めます。多くのアプリケーションでは、これらの設計手法で十分に対応できます。しかし、複数のソースシステムからデータを取り込む大規模なデータウェアハウスを運用する組織では、やがて課題に直面することがあります。スキーマが変更に柔軟に対応しづらくなり、過去のデータの履歴を把握することが難しくなるほか、新しいデータソースを追加するたびに、本番環境で運用中のテーブルの設計変更が必要になることがあります。Data Vault 2.0は、こうした課題を解決するために考案された設計手法です。本記事では、Data Vault 2.0とは何か、その仕組み、そしてNavicat Data Modeler 4で活用する方法について解説します。
Data Vault 2.0とは？
Data Vault 2.0は、Dan Linstedt氏によって開発されたデータモデリング手法です。2000年代初頭に初めて提唱され、その後、2013年頃に大幅な拡張が行われました。初期のバージョンがデータモデリング手法そのものに重点を置いていたのに対し、バージョン2.0では、アーキテクチャパターンや開発手法に加え、アジャイル開発やクラウドコンピューティング、自動化といった現代的な技術や開発手法との統合まで対象を広げています。
基本的な考え方はシンプルです。従来のディメンションテーブルのように、識別情報、関連情報、属性情報を1つのテーブルにまとめるのではなく、Data Vault 2.0では、それらを3種類の異なる構造に分けて管理します。この分離によって、柔軟性と変化への高い適応力を実現しています。
Data Vault 2.0を構成する3つの要素
Hubsは、中核となるビジネス概念を表し、ビジネスキーのみを保持します。ビジネスキーとは、顧客ID、商品コード、注文番号など、組織で実際に使用されている自然な識別子のことです。そのため、顧客を表すHubには、顧客IDのみが格納され、それ以外の情報は保持されません。Hubは安定した構造となるよう設計されており、ソースシステムが変更されても影響を受けず、時間の経過によって変化する可能性のある情報も保持しません。
Linksは、Hub同士の関係を記録します。例えば、顧客が注文を行うと、Linkテーブルには顧客Hubと注文Hubのハッシュキーを保持することで、その関連が記録されます。Linkも追記専用で変更されないため、一度記録された関連はそのまま保持されます。その結果、ビジネスエンティティ間に存在したあらゆる関連を記録する、信頼性の高い監査証跡となります。
Satellitesには、属性情報とその履歴が格納されます。例えば、顧客Hubに関連付けられたSatelliteには、顧客名、住所、連絡先などの属性情報に加え、それぞれの属性がいつ取り込まれたかを示すタイムスタンプが保存されます。SatelliteはHubとは分離されているため、1つのHubに対して複数のSatelliteを持つことができます。例えば、ソースシステムごと、あるいはデータの更新頻度ごとにSatelliteを作成しても、Hub自体を変更する必要はありません。これにより、新しいデータソースを統合する場合でも柔軟に対応できることが、Data Vaultの大きな特長となっています。
Data Vault 2.0が適しているケースと適していないケース
Data Vault 2.0は、多数のソースシステムを統合し、頻繁なスキーマ変更に対応するとともに、データがどのように取り込まれ、どのように変化してきたかを完全な監査証跡として保持する必要があるエンタープライズ向けデータウェアハウスにおいて、その複雑さに見合う価値があります。特に、金融、医療、保険などの規制の厳しい業界では、Hub・Link・Satelliteモデルが構造上備えている高い監査性が大きな利点となります。これは、すべてのデータに、データの取込日時を示すタイムスタンプとソースシステムの情報が標準で記録されるためです。
一方で、よりシンプルな分析用データベースや、データモデリングに十分なリソースを割けない小規模なチーム、あるいは柔軟性よりも統合レイヤーでのクエリのシンプルさやパフォーマンスを重視するアプリケーションには、あまり適していません。Data Vaultはデータ統合レイヤーであり、データ活用レイヤーではありません。そのため、分析者はData Vaultそのものに直接クエリを実行するのではなく、その上に構築されたプレゼンテーションレイヤー（一般的にはスタースキーマやデータマート）を対象に分析を行うことが推奨されます。この役割を区別せずにData Vaultへ直接クエリを実行すると、多数のテーブルを結合する必要があり、クエリが複雑になりがちです。
Navicat Data ModelerによるData Vault 2.0のモデリング
Data Vault 2.0のサポートは、2025年3月にリリースされたNavicat Data Modeler 4で追加されました。これは単体製品として提供されるほか、Navicat 17.2にも搭載されています。Data Vault 2.0は、従来からサポートされているリレーショナルモデリングおよびディメンショナルモデリングと並んで利用できるため、Data Vault 2.0を含む3つのモデリング手法を1つのアプリケーション内で扱えます。
モデリング手法としてData Vault 2.0を選択すると、設計画面やオブジェクトの種類もData Vault 2.0に合わせたものになります。Hub、Link、SatelliteをData Vault本来の形で扱えるため、設計時の分かりやすさが向上するだけでなく、データベースへ展開する際にも、Data Vaultの構造を正しく反映したDDLを生成できます。また、視覚的な設計画面では、Data Vault特有のハブ・アンド・スポーク（Hub and Spoke）構造を一目で把握できるため、各要素（Hub・Link・Satellite）のつながりや、新しいソースシステムのデータをどこへ組み込めばよいかを検討しやすくなります。
Navicat Data Modelerには、Data Vaultの設計だけでなく、その後の開発作業を効率化するための機能も用意されています。物理モデルの設計が完了したら、データベースに同期機能を使用してモデルと実際のデータベースを比較し、差分だけを反映するためのデプロイスクリプトを生成できます。この機能は、Data Vault 2.0の段階的に機能を追加していくスプリントベースの開発スタイルにも適しています。また、モデルをSQL／スクリプトファイルにエクスポート機能では、設計したスキーマ全体のDDLをSQLスクリプトとして出力できるため、そのままバージョン管理システムで管理したり、マイグレーションツールで利用したりできます。さらに、Navicat Data Modelerは、MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、MongoDB、SQLite、Snowflakeなど幅広いデータベースに対応しているため、利用するデータベースが異なっても、同じモデリング手順で設計を進めることができます。
結論
Data Vault 2.0は、すべてのプロジェクトに適した手法というわけではありません。しかし、変化に柔軟に対応し、信頼性の高い監査証跡を維持する必要があるエンタープライズ向けデータウェアハウスを構築する組織にとっては、従来の手法では実現が難しい高い適応力を備えています。Data Vault 2.0の設計思想を理解するには、ある程度の学習が必要です。しかし、「識別情報とリレーションシップを分離する」「リレーションシップと属性情報を分離する」「すべての変更を追跡可能にする」という基本原則も、一度その考え方が腑に落ちれば、とても理にかなったものだと分かります。また、Navicat Data Modeler 4ではData Vault 2.0に標準対応したことで、Data Vaultの構造を画面上でそのまま設計できるようになり、設計内容を実装へスムーズに反映できるようになりました。
