データボールトモデリング

データボールトまたはデータ ボールト モデリングは、複数の運用システムから入ってくるデータの長期履歴ストレージを提供するように設計されたデータベースモデリング方法です。また、監査、データのトレース、読み込み速度、変更に対する回復力などの問題に対処する履歴データを調べる方法であり、データベース内のすべてのデータの出所を追跡する必要性を強調しています。つまり、データ ボールト内のすべての行には、レコード ソースと読み込み日の属性が付いていなければならず、監査人が値をソースまでさかのぼって追跡できるようにする必要があります。この概念は、2000 年にDan Linstedtによって発表されました。

データ ボールト モデリングでは、良いデータと悪いデータ (「悪い」とは、ビジネス ルールに準拠していないことを意味します) を区別しません。^[1]これは、データ ボールトが「事実の単一バージョン」 ( Dan Linstedtは「すべてのデータを常に」とも表現) を保存するというステートメントに要約されています。これは、定義に準拠しないデータが削除または「クリーンアップ」される「真実の単一バージョン」^[2]を保存する他のデータ ウェアハウス方法とは対照的です。データ ボールトのエンタープライズ データ ウェアハウスは、事実の単一バージョンと真実の単一ソースの両方を提供します。^[3]

モデリング方法は、構造情報を記述属性から明示的に分離することにより、保存されるデータの元となるビジネス環境の変化に対応できるように設計されています。^[4]データボールトは、可能な限り並列ロードを可能にするように設計されているため、 ^[5]大規模な実装でも大幅な再設計を必要とせずにスケールアウトできます。

スタースキーマ（ディメンションモデリング）や従来のリレーショナルモデル（3NF）とは異なり、データボールトとアンカーモデリングは、ソースシステムの変更や追加時に発生する変更を捕捉するのに適していますが、経験豊富なデータアーキテクトを必要とする高度な技術と考えられています。^[6]データボールトとアンカーモデルはどちらもエンティティベースのモデルですが、^[7]アンカーモデルはより標準化されたアプローチを採用しています。^[要出典]

当初、Dan Linstedt は、データ ボールトとなるモデリング手法を、共通基礎ウェアハウス アーキテクチャ^[8]または共通基礎モデリング アーキテクチャ^[9]と呼んでいました。データ ウェアハウスモデリングには、データが格納されるレイヤーをモデリングするための 2 つのよく知られた競合するオプションがあります。1 つは、適合ディメンションとエンタープライズ データ バスを使用してRalph Kimballに従ってモデリングする方法、もう 1 つは、データベースを正規化したBill Inmonに従ってモデリングする方法です。^[10]どちらの手法も、データ ウェアハウスにデータを供給するシステムの変更に対処する際に問題があります^[要出典]。適合ディメンションの場合、データをクレンジングする (適合させる) 必要があり、多くの場合、これによって必然的に情報が失われるため、これは望ましくありません^[要出典]。データ ボールトは、これらの問題を履歴ストレージ領域外のデータ ウェアハウスの領域に移動し (クレンジングはデータ マートで実行されます)、構造項目 (ビジネス キーとビジネス キー間の関連付け) を記述属性から分離することで、これらの問題の影響を回避または最小限に抑えるように設計されています。

この方法の作成者である Dan Linstedt 氏は、結果として得られるデータベースについて次のように説明しています。

「データ ボールト モデルは、詳細指向で、履歴追跡機能を備え、一意にリンクされた正規化されたテーブルのセットであり、ビジネスの 1 つ以上の機能領域をサポートします。これは、第 3 正規形 (3NF) とスター スキーマの最良の組み合わせを網羅したハイブリッド アプローチです。設計は柔軟性があり、拡張性があり、一貫性があり、企業のニーズに適応できます。」^[11]

データ ボールトの理念は、確立された定義やビジネス ルールに沿わない場合でも、すべてのデータは関連データであるということです。データがこれらの定義やルールに準拠していない場合、それはデータ ウェアハウスではなくビジネスの問題です。データが「間違っている」という判断は、特定の視点から生じるデータの解釈であり、すべての人に有効であるとは限りません。また、すべての時点で有効であるとは限りません。したがって、データ ボールトはすべてのデータをキャプチャする必要があり、データ ボールトからデータをレポートまたは抽出するときにのみ、データが解釈されます。

データ ボールトが対応するもう 1 つの問題は、データ ウェアハウス内のすべてのデータの完全な監査可能性と追跡可能性がますます必要になっていることです。米国のサーベンス オクスリー法の要件やヨーロッパの同様の措置により、これは多くのビジネス インテリジェンス実装に関連するトピックであるため、データ ボールト実装の焦点は、すべての情報の完全な追跡可能性と監査可能性にあります。

Data Vault 2.0は新しい仕様です。これはオープン スタンダードです。^[12]新しい仕様は、方法論 ( SEI / CMMI、シックス シグマ、SDLCなど)、アーキテクチャ (入力層 (データ ステージ、 Data Vault 2.0 では永続ステージング領域と呼ばれる)、プレゼンテーション層 (データ マート)、データ品質サービスとマスター データ サービスの処理など)、およびモデルの 3 つの柱で構成されています。方法論では、ベスト プラクティスの実装が定義されています。Data Vault 2.0 は、ビッグデータ、NoSQLなどの新しいコンポーネントを含めることに重点を置いており、既存のモデルのパフォーマンスにも重点を置いています。古い仕様 (大部分はここで文書化されています) は、データ ボールトのモデリングに重点を置いています。これは、次の書籍に記載されています: Building a Scalable Data Warehouse with Data Vault 2.0。^[13]

EDW および BI システムを今日のビジネスのニーズと要望に合わせて最新の状態に保つには、ベスト プラクティスとともに新しいコンポーネントを組み込むように仕様を進化させる必要があります。

データ ボールト モデリングは、1990 年代に Dan Linstedt によって考案され、2000 年にパブリック ドメイン モデリング手法としてリリースされました。データ管理ニュースレターの 5 つの記事シリーズでは、データ ボールト手法の基本ルールが詳しく説明されています。これには、一般的な概要、^[14]コンポーネントの概要、^[15]終了日と結合に関する説明、^[16]リンク テーブル、^[17]およびロード方法に関する記事が含まれています。^[18]

この方法の別名（あまり使われない名前）は「共通基礎統合モデリングアーキテクチャ」です。^[19]

Data Vault 2.0 ^{[20] [21]}は2013年に登場し、ビッグデータ、NoSQL、非構造化、半構造化のシームレスな統合、方法論、アーキテクチャ、実装のベストプラクティスをもたらしました。

ダン・リンステッドによると、データモデルは、ニューロン、樹状突起、シナプスの単純な見方からヒントを得た（またはそれを模倣した）もので、ニューロンはハブとハブサテライトに関連付けられ、リンクは樹状突起（情報のベクトル）、その他のリンクはシナプス（反対方向のベクトル）です。データマイニングアルゴリズムセットを使用することで、リンクに信頼性と強度の評価を付けることができます。リンクは、現在存在しない関係についての学習に応じて、オンザフライで作成および削除できます。モデルは、使用されて新しい構造が入力されると、自動的に変形、適応、調整されます。^[22]

別の見方では、データ ボールト モデルは、エンタープライズのドメイン内の用語(ハブ) とそれらの間の関係 (リンク) を記述し、必要に応じて説明的な属性 (サテライト) を追加するという意味で、エンタープライズのオントロジーを提供します。

データ ボールト モデルをグラフィカル モデルとして考えることもできます。データ ボールト モデルは、実際には、リレーショナル データベースの世界におけるハブと関係性を備えた「グラフ ベース」のモデルを提供します。このようにして、開発者は SQL を使用して、1 秒未満の応答でグラフ ベースの関係性を取得できます。

データ ボールトは、ビジネス キー (ビジネス エンティティを一意に識別するため、それほど頻繁に変更されることはありません) とそれらのビジネス キー間の関連付けを、それらのキーの説明属性から分離することによって、環境の変化に対処するという問題を解決しようとします。

ビジネス キーとその関連付けは構造属性であり、データ モデルの骨組みを形成します。データ ボールト メソッドの主な公理の 1 つは、実際のビジネス キーはビジネスが変化した場合にのみ変更されるため、履歴データベースの構造を導出するための最も安定した要素であるということです。これらのキーをデータ ウェアハウスのバックボーンとして使用すると、残りのデータをキーを中心に整理できます。つまり、ハブに適切なキーを選択することが、モデルの安定性にとって最も重要です。^[23]キーは、構造にいくつかの制約があるテーブルに格納されます。これらのキー テーブルはハブと呼ばれます。

ハブには、変更される可能性が低い一意のビジネス キーのリストが含まれています。ハブには、各ハブ項目の代理キーと、ビジネス キーの起源を説明するメタデータも含まれています。ハブの情報の説明属性 (キーの説明など、複数の言語で記述される場合もあります) は、以下で説明するサテライト テーブルと呼ばれる構造に格納されます。

ハブには少なくとも以下のフィールドが含まれています: ^[24]

• 他の構造をこのテーブルに接続するために使用される代理キー。
• ビジネスキー、このハブのドライバー。ビジネス キーは複数のフィールドで構成できます。
• レコード ソース。これを使用して、各ビジネス キーを最初にロードしたシステムを確認できます。
• オプションで、手動更新 (ユーザー/時間) と抽出日に関する情報を含むメタデータ フィールドも使用できます。

2 つのシステムが同じビジネス キーを配信するが、意味が異なる衝突が発生する場合を除き、ハブに複数のビジネス キーを含めることはできません。

ハブには通常少なくとも1つの衛星が必要です。^[24]

これは、「Car」(H_CAR) と呼ばれる自動車を含むハブ テーブルの例です。駆動キーは車両識別番号です。

ビジネス キー間の関連付けまたはトランザクション (たとえば、購入トランザクションを通じて顧客と製品のハブを相互に関連付ける) は、リンク テーブルを使用してモデル化されます。これらのテーブルは基本的に、いくつかのメタデータを含む多対多の結合テーブルです。

リンクは、粒度の変更に対応するために、他のリンクにリンクできます (たとえば、データベース テーブルに新しいキーを追加すると、データベース テーブルの粒度が変更されます)。たとえば、顧客と住所が関連付けられている場合、製品と輸送会社のハブ間のリンクへの参照を追加できます。これは、「配送」というリンクになります。別のリンク内のリンクを参照することは、リンク間の依存関係が生じて並列読み込みが困難になるため、悪い習慣と見なされます。別のリンクへのリンクは、他のリンクからのハブを含む新しいリンクと同じであるため、このような場合は、他のリンクを参照せずにリンクを作成することが推奨される解決策です (詳細については、読み込み方法のセクションを参照してください)。

リンクは、ハブを構築するにはそれだけでは不十分な情報にハブをリンクすることがあります。これは、リンクによって関連付けられたビジネス キーの 1 つが実際のビジネス キーではない場合に発生します。例として、「注文番号」をキーとする注文フォームと、一意になるように半ランダムな番号でキー設定された注文明細を取り上げます。「一意の番号」とします。後者のキーは実際のビジネス キーではないため、ハブではありません。ただし、リンクの適切な粒度を保証するために、これを使用する必要があります。この場合、代理キーを持つハブは使用せず、ビジネス キー「一意の番号」自体をリンクに追加します。これは、ビジネス キーを別のリンクに使用する可能性がまったくない、またはサテライトの属性のキーとして使用する可能性がない場合にのみ行われます。この構成は、Dan Linstedt によって (現在は廃止された) フォーラムで「peg-legged link (義足リンク)」と呼ばれています。

リンクには、リンクされているハブの代理キー、リンクの代理キー、および関連付けの起源を説明するメタデータが含まれます。関連付けに関する情報の説明属性 (時間、価格、金額など) は、以下で説明する サテライト テーブルと呼ばれる構造に保存されます。

これは、車 (H_CAR) と人 (H_PERSON) の 2 つのハブ間のリンク テーブルの例です。リンクは「ドライバー」(L_DRIVER) と呼ばれます。

ハブとリンクはモデルの構造を形成しますが、時間属性はなく、記述属性も保持しません。これらは、サテライトと呼ばれる別のテーブルに保存されます。これらは、親ハブまたはリンクにリンクするメタデータ、関連付けと属性の起源を説明するメタデータ、および属性の開始日と終了日を含むタイムラインで構成されます。ハブとリンクがモデルの構造を提供するのに対し、サテライトはモデルの「中身」、つまりハブとリンクでキャプチャされるビジネス プロセスのコンテキストを提供します。これらの属性は、問題の詳細とタイムラインの両方に関して保存され、非常に複雑なもの (クライアントの完全なプロファイルを説明するすべてのフィールド) から非常に単純なもの (有効インジケータとタイムラインのみを持つリンク上のサテライト) までさまざまです。

通常、属性はソース システムごとにサテライトにグループ化されます。ただし、サイズ、コスト、速度、量、色などの説明的な属性は異なる速度で変化する可能性があるため、変化率に基づいてこれらの属性を異なるサテライトに分割することもできます。

すべてのテーブルにはメタデータが含まれており、少なくともソース システムとこのエントリが有効になった日付が記述されており、データ ウェアハウスに入るデータの完全な履歴ビューが提供されます。

有効性衛星はリンク上に構築された衛星であり、「対応するリンクが開始有効性と終了有効性を記録する期間を記録する」ものである。^[26]

これは、自動車と人のハブ間のドライバーリンク上のサテライトの例で、「ドライバー保険」(S_DRIVER_INSURANCE) と呼ばれます。このサテライトには、自動車とそれを運転する人との関係の保険に固有の属性が含まれています。たとえば、これが主なドライバーであるかどうかの指標、この自動車と人の保険会社の名前 (別のハブになる場合もあります)、およびこの自動車とドライバーの組み合わせに関連する事故件数の要約などです。また、この関係が該当するとみなされるリスク カテゴリのコードを含む、R_RISK_CATEGORY と呼ばれる参照テーブルへの参照も含まれています。

(*) 少なくとも 1 つの属性が必須です。 (**) 同じハブまたはリンク上の複数の有効な衛星の一意性を強制する必要がある場合は、シーケンス番号が必須になります。

参照テーブルは、健全なデータ ボールト モデルの通常の一部です。参照テーブルは、頻繁に参照される単純な参照データの冗長な保存を防ぐために存在します。より正式には、Dan Linstedt は参照データを次のように定義しています。

コードから説明を解決したり、キーを一貫した方法に変換したりするために必要と思われる情報。これらのフィールドの多くは本質的に「説明的」であり、他のより重要な情報の特定の状態を説明します。そのため、参照データは生の Data Vault テーブルとは別のテーブルに保存されます。^[27]

参照テーブルはサテライトから参照されますが、物理的な外部キーにバインドされることはありません。参照テーブルには規定の構造はありません。単純なルックアップテーブルから小さなデータボールト、さらにはスターまで、特定のケースに最適なものを使用してください。参照テーブルは履歴がある場合も履歴がない場合もありますが、その場合は自然キーを使用し、代理キーを作成しないことをお勧めします。^[28]通常、データボールトには、他のデータウェアハウスと同様に、多くの参照テーブルがあります。

これは、車両の運転手のリスク カテゴリを含む参照テーブルの例です。データ ボールト内の任意の衛星から参照できます。ここでは、衛星 S_DRIVER_INSURANCE から参照します。参照テーブルは R_RISK_CATEGORY です。

(*) 少なくとも 1 つの属性は必須です。

データ ボールト モデルを更新するためのETLは非常に簡単です (「データ ボールト シリーズ 5 – ロード プラクティス」を参照)。まず、すべてのハブをロードして、新しいビジネス キーの代理 ID を作成する必要があります。これを実行すると、ハブをクエリすると、すべてのビジネス キーを代理 ID に解決できるようになります。2 番目の手順は、ハブ間のリンクを解決し、新しい関連付けの代理 ID を作成することです。同時に、キーを代理 ID に解決できるため、ハブに接続されているすべてのサテライトを作成することもできます。代理キーを使用してすべての新しいリンクを作成したら、すべてのリンクにサテライトを追加できます。

ハブはリンク以外では相互に接続されていないため、すべてのハブを並列にロードできます。リンクは互いに直接接続されていないため、すべてのリンクを並列にロードすることもできます。サテライトはハブとリンクにのみ接続できるため、これらを並列にロードすることもできます。

ETLは非常に単純で、自動化やテンプレート化が容易です。問題は、リンク内のビジネスキーを解決すると、解決する必要がある別のリンクにつながるだけなので、他のリンクに関連するリンクでのみ発生します。この状況は複数のハブへのリンクと同等であるため、このようなケースを改造することでこの問題を回避でき、これは実際に推奨される方法です。^[18]

データの読み込み中に技術的なエラーが発生しない限り、データはデータ ボールトから削除されることはありません。

データ ボールト モデル レイヤーは通常、データを格納するために使用されます。クエリ パフォーマンスが最適化されておらず、Cognos、Oracle Business Intelligence Suite Enterprise Edition、SAP Business Objects、Pentahoなどのよく知られたクエリ ツールでクエリを実行することも容易ではありません。^[要出典]これらのエンド ユーザー コンピューティング ツールでは、データがディメンション モデルに含まれていることが想定または好まれるため、通常は変換が必要です。

この目的のために、ハブとそれらのハブ上の関連サテライトはディメンションとみなされ、リンクとそれらのリンク上の関連サテライトはディメンション モデル内のファクト テーブルとして表示できます。これにより、ビューを使用してデータ ボールト モデルからディメンション モデルを迅速にプロトタイプ化できます。

データボールトモデルから（クレンジングされた）ディメンションモデルにデータを移動するのは比較的簡単ですが、その逆は、ディメンションモデルのファクトテーブルの非正規化の性質（データボールトの第3正規形とは根本的に異なる）を考えると、それほど簡単ではありません。 ^[29]

データ ボールト方法論は、SEI / CMMIレベル 5 のベスト プラクティスに基づいています。CMMI レベル 5 の複数のコンポーネントが含まれ、それらをシックス シグマ、総合的品質管理(TQM)、および SDLC のベスト プラクティスと組み合わせます。特に、構築と展開のための Scott Ambler のアジャイル方法論に重点を置いています。データ ボールト プロジェクトは、短い範囲で制御されたリリース サイクルを持ち、2 ～ 3 週間ごとに本番リリースを行う必要があります。

データ ボールト方法論を使用するチームは、CMMI レベル 5 で期待される、反復可能で一貫性があり測定可能なプロジェクトに容易に適応できるはずです。EDW データ ボールト システムを通過するデータは、BI (ビジネス インテリジェンス) プロジェクトでは長い間欠けていた TQM ライフ サイクルに従うようになります。

ツールの例をいくつか挙げると次のとおりです: ^{[説明が必要]}

• 2150 データボルトビルダー
• アステラ DW ビルダー
• 場所
• ヴォルトスピード
• 自動化DV

• ビル・インモン – アメリカのコンピューター科学者
• データレイク – 自然な/生の形式で保存されたデータのシステムまたはリポジトリ
• データ ウェアハウス – 知識の集中保管
• キンボールライフサイクルは、アメリカのコンピュータ科学者であり、データウェアハウスの共同創設者でもあるラルフ・キンボールフォールバックとしてウィキデータの説明を表示するページによって開発された、 データウェアハウスまたはビジネスインテリジェンスシステムを設計、開発、展開するために使用さ れる高レベルのシーケンスタスクです。フォールバックとしてウィキデータの説明を表示するページ
• ステージングエリア – 使用前にアイテムを集める場所
• アジャイルビジネスインテリジェンス

• Patrick Cuba: データ ボールトの第一人者。データ ボールト構築に関する実践的なガイド。Selbstverlag、Ohne Ort 2020、ISBN 979-86-9130808-6。
• John Giles: 冷蔵庫の中の象。ビジネス中心のモデルの構築によるデータ ボールト成功へのガイド付き手順。Technics、Basking Ridge 2019、ISBN 978-1-63462-489-3。
• Kent Graziano: より優れたデータ モデリング。Data Vault 2.0 を使用したアジャイル データ エンジニアリング入門。Data Warrior、ヒューストン、2015 年。
• Hans Hultgren: Data Vault を使用したアジャイル データ ウェアハウスのモデリング。Brighton Hamilton、Denver ua 2012、ISBN 978-0-615-72308-2。
• Dirk Lerner: アジャイル データ ウェアハウス アーキテクチャのための Data Vault。執筆者: Stephan Trahasch、Michael Zimmer (Hrsg.): アジャイル ビジネス インテリジェンス。理論と実践。 dpunkt.verlag、ハイデルベルク、2016、ISBN 978-3-86490-312-0、S. 83–98。
• Daniel Linstedt: データ ウェアハウスを超強化。データ ボールトを実装するための貴重なデータ モデリング ルール。Linstedt、セント アルバンズ、バーモント州、2011 年、ISBN 978-1-4637-7868-2。
• Daniel Linstedt、Michael Olschimke: Data Vault 2.0 を使用したスケーラブルなデータ ウェアハウスの構築。Morgan Kaufmann、マサチューセッツ州ウォルサム、2016 年、ISBN 978-0-12-802510-9。
• Dani Schnider、Claus Jordan ua: データ ウェアハウスのブループリント。実践におけるビジネス インテリジェンス。ハンザー、ミュンヘン、2016 年、ISBN 978-3-446-45075-2、S. 35–37、161–173。

• Data Vault モデリングの発明者 Dan Linstedt のホームページ