Data Vault のリンクとは？

ハブを見れば、どのような顧客、製品、受注が存在するかが分かります。しかし、それらがどのように結び付いているかは分かりません。それを担うのがリンクです。

従来のモデリングの用語で言えば、リレーションシップがリンクになります。簡単に言うと、第3正規形モデルの外部キーがリンクの基礎です。Order テーブルが customer_id を持っている場合、Data Vault には受注ハブと顧客ハブを結ぶリンクがあります。

従来型のリンク

リンクはビジネスキー間のリレーションシップを記録します。この受注はこの顧客のものである、この契約はこの製品を対象としている、といった関係です。ハブと同様に、説明的なデータは保存しません。

リンクテーブルには次のカラムがあります。

• リンクハッシュキー： 主キーです。リンクが結ぶすべてのハブのビジネスキーから計算したハッシュです。
• ハブハッシュキー： 関係する各ハブにつき 1 カラムです。
• Load Date： リレーションシップが初めて確認された日時です。
• Record Source： そのリレーションシップを提供したシステムです。

リンクはハブと同じく挿入専用です。一度確認されたリレーションシップはリンクに残り続けます。それが現在も有効かどうかはエフェクティビティサテライトで扱う問題で、このシリーズの後の記事で取り上げます。

教科書どおりの Data Vault では、すべてのリンクを多対多としてモデリングします。そうしておけば、企業合併や新システムの導入によって一対多が多対多に変わっても、リンクを作り直す必要がないからです。ただし、構造が多対多であっても、データが多対多であるとは限りません。受注が別の顧客に移された場合、その受注が 2 人の顧客に属するようになったわけではありません。新しい顧客が古い顧客に置き換わったのです。リンクを正しく読むには、その主導側を知っておく必要があります。

Datavault Builder では、従来型のリンクは 2 つのハブを結ぶバイナリリンクであり、1:1、n:1、1:n、n:m のいずれかのカーディナリティを持ちます。カーディナリティによってリレーションシップのどちら側が主導側かが決まるため、主導側での変更はリレーションシップの追加ではなく、置き換えとして解釈されます。

従来のデータモデリングをご存じなら、リンクもすでにご存じのはずです

トランザクションリンク

トランザクションのために、Datavault Builder は 2 つ目の種類のリンクを備えています。受注明細、支払い、出荷明細といったトランザクションは複数のハブに同時に関係するため、従来の Data Vault ではトランザクションをそのままリンクに入れることがよくあります。場合によっては、依存子キー（dependent child key）を持つ非履歴化リンクとして扱います。この場合、粒度は暗黙的なものになります。たまたま行を一意にしているキーの組み合わせが、そのまま粒度になるのです。後でソースが受注明細を別の顧客に移すと、そのリンクには同じ明細について 2 行が存在することになり、どちらがトランザクションを表しているのかはモデルのどこにも示されません。

トランザクションリンクは粒度を明示します。トランザクションの最小粒度に専用のハブ、つまりグレインハブ（Hub_Sales_Order_Line、Hub_Payment_Transaction）を設け、リンクはそれを基点とします。これによってトランザクションリンクは 4 つの特性を持ち、それぞれに理由があります。

• 粒度が固定されている： 受注明細 1 件につきリンクのエントリは 1 件で、粒度がずれることはありません。

• 主導側が定義されている： グレインハブがリレーションシップの主導側です。受注明細に新しい製品が設定された場合、新しい製品が古い製品に置き換わります。明細が同時に 2 つの製品を指すようになるわけではありません。

• 識別関係と非識別関係： グレインハブはトランザクションの識別情報です。顧客、製品、店舗は参照として関与します。これは従来の ER モデリングと同じ区別です。

  「キーを、キー全体を、そしてキーのみを。Codd に誓って。」 Codd の第3正規形を要約したこの古典的な言葉は、ここでも当てはまります。グレインハブはトランザクションのキーであり、それ以外のものはすべて、トランザクションを説明するか、別の概念を参照するかのどちらかです。

• 属性はハブに持たせる： 数量、価格、ステータスは、グレインハブ上の通常のサテライトに格納します。他のサテライトと同様に差分ロードでき、後から属性を追加してもモデルを作り直す必要はありません。Data Vault ではこの用途にリンクサテライトを使うこともできますが、私たちの経験では、ハブに持たせるほうが適しています。同じことは、顧客と契約の割り当てに付くロールや割合のように、属性を持つ関連テーブルにも当てはまります。

リンクからリンクへの参照という問題の解決

Data Vault の第一のルールは、リンクはハブ同士を結ぶというものです。リンクが別のリンクを参照することはできません。

しかし現実のトランザクションは、ごく日常的に別のトランザクションと関係しています。請求明細は出荷明細に対応し、支払いは請求書を決済し、返品は受注明細を参照します。従来の回避策は、すべてを 6 つ以上のハブキーを持つ 1 つの複合リンクにまとめてしまうことですが、これは読みにくく、ロードのたびに大きな作業単位（unit of work）が発生します。

トランザクションリンクを使えば、この問題はなくなります。すべてのトランザクションにはすでにグレインハブがあるため、2 つのトランザクション間のリレーションシップは、2 つのハブを結ぶ通常のリンクになります。

Hub_Delivery_Line ↔ Link_Delivery_To_Invoice ↔ Hub_Invoice_Line

リンクからリンクへの参照も、依存子キーによる回避策も必要なく、どのリンクも読み解ける大きさに収まります。

このパターンは 2017 年にさかのぼります。私が 『Data Vaultにおけるリンクの考察』 で初めて説明したもので、Data Vault 2.0 の標準との比較もそこで取り上げています。

Datavault Builder で何が変わるか

• 両方の種類のリンクを 1 つのモデルで： マスターデータ間のリレーションシップにはバイナリリンクを、リレーションシップがトランザクションである場合にはトランザクションリンクを使います。
• カーディナリティと粒度はモデル上の判断です： バイナリリンクのカーディナリティ、あるいは 1 件のトランザクションが何であるかを指定すれば、ツールがそこからリンクとそのロード処理を構築します。
• コードは自動生成されます： ハッシュキー、作業単位、挿入専用のロードは、Snowflake、Databricks、BigQuery、SQL Server、Fabric、Oracle、PostgreSQL のいずれでも、すべてのリンクで同じパターンに従います。

判断すべきこと

最も重要なトランザクションを 3 つ選び、それぞれについて、1 件の発生が何であるかを書き出してください。答えが明細番号や伝票番号ではなく、顧客、製品、日付の組み合わせになるなら、粒度は暗黙的です。そこが、トランザクションリンクによってモデルを安定させられる箇所です。