Data Vault のビジネスキーとは？
ビジネスキーとは、従業員や顧客が実際に使っている識別子です。顧客番号、請求書番号、契約 ID などがこれに当たります。安定していて、システムをまたいで共有されており、Data Vault のすべてのハブはこのキーを土台に構築されます。
さまざまな業界のデータチームから信頼されるデータウェアハウス自動化ソリューション
このような課題はありませんか？
- モデルをデータベーススキーマを基に設計したため、その中にビジネス部門が見て分かるキーが 1 つもない。
- ERP の移行後、すべての顧客に新しい ID が振られ、履歴が結合できなくなった。
- 2 つのシステムが同じ顧客を保持しているのに、データウェアハウスはどのレコード同士が対応するのかを判断できない。
ハブの良し悪しは、その土台となるキーで決まります。Data Vault で成功の鍵を握るのは、ビジネスキーです。
ビジネスキーとは何か
ビジネスキーとは、ビジネスの現場そのものが使っている識別子です。手紙に記載された顧客番号、顧客が電話で伝える請求書番号、メールに書かれた契約 ID などがこれに当たります。従業員も顧客もこれらのキーを知っており、だからこそ安定しています。システムは内部の行に番号を振り直すことができますが、1 万枚の請求書に印刷された番号は簡単には変えられません。
従来のデータモデリングの用語で言えば、ビジネスキーは自然キーです。データベースが自身の都合で生成するサロゲートキーとは異なり、エンティティの候補キーの 1 つです。概念モデルの主キーを選んだことがあれば、この作業はすでに経験済みです。
見つけ方：紙の請求書を使う方法
多くのデータエンジニアやモデラーは、ビジネス部門の担当者にキーについて尋ねることをためらいます。質問が技術的に聞こえ、答えがテーブル名の話にそれていくからです。簡単な方法で、これを避けられます。
- ビジネス部門の担当者に、実際の書類をいくつか印刷してもらいます。受注書、請求書、納品書などです。
- 次のように尋ねます。「顧客がこの書類のことで電話してきたら、その書類を探し出せるように、顧客は何を伝えてきますか？」
- 担当者が指し示したものに印を付けます。
印を付けた識別子が、ビジネスキーです。同じ 1 枚の紙からは、その周りにある概念（顧客、受注、製品）と、それらが互いにどう関係しているかも分かります。これがモデルの出発点になります。
Data Vault がビジネスキーを土台にする理由
- パッシブ統合： ビジネスキーはソースシステム間で共有されています。CRM と ERP がどちらも顧客
C-10442を同じハブにロードすれば、手作業の統合ロジックがなくても両者のデータは結び付きます。共有されたキーと私たちの自動化がその役割を担います。 - ソースシステムの移行： ソースシステムが置き換えられると、その技術キーは変わります。ビジネスキーは変わらないため、移行前後の履歴は引き続き一致します。
- データウェアハウスの世代交代： 同じことはデータウェアハウスそのものにも当てはまります。新しいデータ統合基盤や DWH ソリューションが古いものからデータを引き継ぐ必要がある場合、ビジネスキーが両者をつなぎます。ビジネスキーは DWH のバージョン間でも安定しているからです。
スイスとドイツの ERP にある受注 1018 のように、同じキーがシステムによって異なるものを意味する場合は、Business Key Prefix によって両者を区別します。会社コードと顧客番号のように、キーが複数の部分からなる場合は、ビジネスキーは複合キーになるだけです。
落とし穴
ほとんどのソースシステムは、ビジネスキーを、そのキーが定義するエンティティ自体に保存しています。顧客番号は顧客テーブルにあります。ところが、リレーションシップには技術キーが使われます。受注の行が持っているのは、顧客番号ではなく、システム内部の顧客 ID です。そこからビジネスキーに基づくモデルへどう到達するかは、このシリーズの次の記事技術キー対ビジネスキーで取り上げます。
Datavault Builder で何が変わるか
Datavault Builder では、概念を一度定義します。次に、各ソースのどのカラムがビジネスキーを構成するかを定義して、すべてのソースをその概念にマッピングします。統合に必要な処理は Datavault Builder がすべて行い、ハブ、キーの処理、ロードのコードが自動生成されます。労力を注ぐのはビジネス部門との対話であり、ロードロジックを書くことではありません。
貴社のデータソースで実際の動作をご確認ください
無料デモをお申し込みいただき、費用や保守工数が最もかかっているコネクタをお持ち寄りください。
ビジネスキーを見つける3つのステップ
-
書類を印刷する
最初の打ち合わせに、実際の受注書、請求書、納品書を持ってきてもらうよう、ビジネス部門の担当者に依頼します。
-
1 つだけ質問する
顧客がこの書類について電話してきたら、それを特定するために何を伝えてきますか？
-
答えに印を付ける
担当者が指し示す識別子は、すべてビジネスキーです。書類からは、概念とそれらの関係も読み取れます。
Datavault Builder がデータ取り込みの摩擦を解消する仕組み
-
取り込み機能を標準で統合
データベース、ファイル、REST API、NoSQL、Python ソースからのバッチ・差分・CDC ロードに対応し、Kafka などのストリームもマイクロバッチとして取り込み可能。ウェアハウス生成と同一の単一プラットフォームで完結し、追加のツール費用は不要です。
-
ベンダー仕様ではなく自社設計のスキーマ
ソーステーブルは自社で設計した Data Vault 2.0 モデルにマッピングされます。カラム追加やテーブル名変更が発生しても、マッピングを調整するだけで対応でき、ロード後のスクリプト修正作業は不要です。
-
差分（デルタ）のみを転送・処理
Hub、Link、Satellite は変更分のみを効率的にロードします。フルリロードデータはステージングに留まり、下流で毎晩再処理されるような無駄な負荷を発生させません。
-
設計段階から変更履歴を確実に保持
すべての変更履歴が到着順に記録されるため、ソース側でレコードが上書きされても過去時点の正確な状態（as-was）を遡って集計・レポーティングできます。
-
手作業でのコーディングは一切不要
ロード処理、履歴管理、データリネージはモデルからリアルタイムで自動生成され、Snowflake、Databricks、BigQuery、SQL Server、Fabric、Oracle、PostgreSQL 上でネイティブに実行されます。
-
1 つのプラットフォームで最大 9 つのツールを集約
モデリング、ETL、CI/CD、ドキュメント生成、リネージ管理を 1 つの環境に統合。要件定義から本番環境へのデプロイまでわずか 14.7 分という迅速なデリバリーを実現します。
BARC「The Data Fabric Survey 26」で高評価を獲得
専門家にご相談ください
弊社のセールスディレクターが 20 分間で、貴社の技術スタックに適合するか率直にお答えします。
Matt Collett
Sales Director
ご都合の良い日時をお選びください：
本シリーズで解説するその他の課題
-
Data Vault における技術キーとビジネスキー
ソースシステムはビジネスキーをマスターレコードに保持していますが、リレーションシップはすべて技術キーで成り立っています。これに対処する 4 つの方法とそれぞれの代償、そして私たちが使っているパターンを紹介します。技術キー用の PSA ハブを設け、それをビジネスキーのハブにマッピングするパターンです。
-
Data Vault のサテライトとは？
サテライトは、ハブを説明するすべての情報を保持します。名称、ステータス、金額、そしてそれらに対するすべての変更です。変更は追記され、更新されることはありません。UPDATE を使わない Slowly Changing Dimension タイプ2 であり、完全な監査証跡が最初から組み込まれています。
-
Data Vault のリンクとは？
リンクはビジネスキー間のリレーションシップを記録します。この受注はこの顧客のものである、といった関係です。Datavault Builder は Data Vault の従来型のリンクに対応するとともに、グレインハブを基点とするトランザクションリンクを備えています。トランザクションリンクはトランザクションの粒度を固定し、トランザクション同士を関連付けられるようにします。
-
Data Vault のハブとは？
ハブは、顧客、製品、口座といったビジネス上の中核概念を、そのキーの一覧として表します。データウェアハウスがこれまでに受け取ったすべてのキーを、それぞれ一度だけ保持します。保存するのは状態ではなく識別情報であり、この割り切りによって、ハブはソースシステムごとのサイロが解消される場所になります。
よくあるご質問
- Dan Linstedt です。1990 年代にこの手法を開発し、2000 年ごろに公開しました。モデルにハッシュキー、方法論、アーキテクチャを加えた Data Vault 2.0 は 2013 年に登場しました。
- 標準的な参考書は、Dan Linstedt と Michael Olschimke による Building a Scalable Data Warehouse with Data Vault 2.0（Morgan Kaufmann、2015 年）です。
- いいえ。Bill Inmon は Data Vault を、第3正規形に基づくエンタープライズデータウェアハウスという自身の考え方を発展させたものと位置づけており、競合するアプローチとは見ていません。
- いいえ。ディメンショナルな出力は、多くの場合 Data Vault 実装の一部です。Vault が統合された履歴を保持し、その上にレポート用のスタースキーマを構築します。同じ Vault から、フラットなテーブルや Unified Star Schema を提供することもできます。
- 自動化を利用すれば、Data Vault の上に第3正規形のビューを完全に決定論的に生成できます。データは Vault に一度だけ保持され、3NF のレイヤーはモデルから導出されます。その仕組みはこちら。
- 自動化せずに取り組むことです。Data Vault は、少数の厳密で繰り返し現れるパターンの上に成り立っています。だからこそ手作業で書くと手間がかかり誤りも生じやすく、逆に生成するのは容易です。Datavault Builder を使うべき理由はそこにあります。
- はい。キー、リレーションシップ、履歴をハブ、リンク、サテライトに分けるため、正規化モデルやディメンショナルモデルよりもテーブルは多くなります。そのため物理レイヤーは、Datavault Builder のようなモデル駆動型のアプローチで抽象化すべきです。作業はビジネスモデルに対して行い、テーブルは自動生成されます。
- デモを予約して自社のソースで Data Vault が構築される様子をご覧いただくか、トレーニング環境を注文してご自身で試してみてください。
- Datavault Builder は年間ライセンスで、ソフトウェアを利用するためのサブスクリプションとして提供されます。永続ライセンスはご要望に応じてご用意します。各エディションとその内容は料金ページに掲載しています。