データの統合（Integration）と結合（Unioning）：ハブ設計の真価

Data Vault モデリングにおいて、私たちはデータを統合するために「ハブ（Hub）」を使用します。これは誰もが知っている基本です。異種データソースからのデータを統合することこそが、私たちが Data Vault を選択する最大の理由の 1 つです。しかし、「統合」とは具体的に何を意味するのでしょうか？ 驚くべきことに、私たちが実務で実際にどうデータを統合しているのかについての本質的な議論は、これまであまりなされてきませんでした。

本稿では、あえて概念をシンプルに整理して解説します。Carsten Schweiger との議論を通じて、私たちはデータ処理において明確に区別すべき 2 つのパターンを定義しました。それが「統合（Integration）」と「結合（Unioning）」です。

統合（Integration） vs. 結合（Unioning）

この違いを正しく理解することは極めて重要です。なぜなら、これによってデータを最適に処理するためのアーキテクチャが根本から変わるからです。それぞれの特性を見ていきましょう：

1. 統合（Integration）

これは「パッシブ統合（受動的統合）」とも呼ばれます。異なる 2 つのソースシステムが「同一のビジネスキー」を共有しているケースです。実務でよく見られる典型例は「商品コード（Product Number）」です。複数のシステム間で共通のコード体系が共有されている場合が該当します。

例えば、スイスと日本の定価を比較したい場合を考えてみましょう。スイスの ERP データと日本の ERP データを 1 つの「商品ハブ（Product Hub）」にロードします。商品コードはプレフィックス（接頭辞）なしでそのままハブに格納され、それぞれの属性は「スイス用サテライト」と「日本用サテライト」へと別々にロードされます。

ここで Data Vault の上位に出力インターフェース（Datavault Builder ではこれを「ビジネスオブジェクト」と呼びます）を作成する場合、ハブからすべてのキーを選択します。そして、スイスの定価を 1 つの列に、日本の定価を別の列に並べて出力できます。

もし「スイスの定価をマスターとするが、日本限定商品も存在する」という要件であれば、優先順位ルールを適用した 3 つ目の列を定義できます。「スイスの価格が存在すればそれを採用し、空であれば日本の価格を採用する」といったルールです。

これこそが、多くの人が Data Vault プロジェクトを開始する際に頭に思い描いている「統合」のユースケースです。

2. 結合（Unioning）

では、なぜ「結合（Unioning）」を別のパターンとして区別する必要があるのでしょうか？

決定的な違いは、2 つのソースシステムから届くデータセットが**「重複せず、互いに排他的（Non-overlapping / Exclusive）」**である点にあります。

代表的な例が「受注ハブ（Order Hub）」です。スイスと日本の注文データをこのハブに集約する場合、スイスの「注文番号 101」と日本の「注文番号 101」は同一の番号範囲（値）を取り得ますが、業務上はまったく別の注文です。

これは次のことを意味します：

• データセットを識別・分離するために、注文番号にシステム識別プレフィックスを付与する必要がある
• 2 つのシステムの注文を複雑なロジックで無理やり「横に結合（Join）」するために無駄な計算リソースを消費する必要がない
• プレゼンテーション層に至るまでデータを物理的に分離したまま扱えるため、結合処理に伴うデータ量を劇的に削減できる
• Data Vault へのロード処理を完全に並列化できる
• Data Vault からデータを抽出するクエリも完全に並列化できる

幸いなことに、エンタープライズにおいて膨大なデータ量を占めるトランザクションの多くは「統合」ではなく「結合（Unioning）」のデータセットです。

結合ハブ（Unioning Hub）を独立したパターンとして扱うメリット

結合ハブを独立した設計パターンとして採用することで、以下の最適化が可能になります：

• ビジネスキーのプレフィックス化： 意味の異なる重複番号を確実に分離。
• システム別にパーティション分割されたリンクテーブル（または個別リンク）： 各ソースシステムからのロードを完全並列で実行可能。
• クエリ効率の劇的な向上： 各ソースシステムで結合される行数が大幅に削減され、その削減効果はソースシステムの数に応じて指数関数的に高まる。
• アウトプットの個別準備： 列名の統一や型変換を、システム単位で仮想的に個別処理可能。
• ビジネスルールの個別適用： システムごとの固有ルールを独立して処理。
• ユニオン出力の自動生成： 最終段階で、自動生成された UNION ALL 構文によって各ソースのデータを高速に集約。
• データベースの並列実行とプッシュダウン： データベースエンジンがソースごとのデータ抽出を並列実行し、特定データセットに対するフィルター条件を Data Vault 側へプッシュダウン可能。

これにより、全データセットの高速な準備が可能になるだけでなく、特定システムに絞ったフィルタリングや特定サテライト列へのプッシュダウンも極めて高効率に行えます。

「統合」と「結合」を明確に区別することで、膨大なデータ量を抱えるエンタープライズエンティティに対して最適な処理パターンを適用できます。さらに、データモデル上でこの意図を明示することにより、データパイプラインの目的が明確化され、どのアブジェクト同士を結合すれば意味のある分析結果が得られるのかが誰の目にも明らかになります。

統合と結合の全自動化

Datavault Builder を使用することで、これら 2 つのユースケースをどのように全自動で設定・実装できるかを、以下の実演動画でご覧いただけます：