データボルトまたはデータボルトモデリングは、複数の運用システムから入力されるデータの長期履歴保存を提供するために設計されたデータベースモデリング手法です。また、監査、データ追跡、読み込み速度、変更への耐性といった問題に対処する履歴データの分析手法でもあり、データベース内のすべてのデータの取得元を追跡する必要性を重視しています。つまり、データボルト内のすべての行には、レコードソースと読み込み日の属性が付与され、監査人が値のソースを遡って追跡できるようにする必要があります。この概念は2000年にDan Linstedtによって発表されました。
データボールトモデリングでは、良質データと不良データの区別はありません（「不良」とは、ビジネスルールに準拠していないデータを意味します）。[1]これは、データボールトが「事実の単一バージョン」（ダン・リンステッドは「すべてのデータを常に」と表現しました）を保存するという表現に要約されます。これは、他のデータウェアハウス手法では「真実の単一バージョン」[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]
データボールトの理念は、たとえ既存の定義やビジネスルールに沿っていなくても、すべてのデータは関連性のあるデータであるということです。データがこれらの定義やルールに準拠していない場合、それはデータウェアハウスの問題ではなく、ビジネスの問題です。データが「間違っている」という判断は、特定の視点に基づくデータの解釈であり、必ずしもすべての人にとって、あるいはすべての時点で有効であるとは限りません。したがって、データボールトはすべてのデータを取得し、レポート作成時またはデータボールトからデータを抽出する場合にのみ、データの解釈を行う必要があります。
データボールトが対応すべきもう一つの課題は、データウェアハウス内のすべてのデータに対する完全な監査可能性とトレーサビリティの必要性がますます高まっていることです。米国のサーベンス・オクスリー法や欧州の同様の措置により、これは多くのビジネスインテリジェンス実装に関連するトピックとなっており、そのため、あらゆるデータボールト実装の焦点は、すべての情報の完全なトレーサビリティと監査可能性にあります。
Data Vault 2.0は新しい仕様で、オープンスタンダードです。[12]新しい仕様は3つの柱で構成されています。方法論（SEI / CMMI、シックスシグマ、SDLCなど）、アーキテクチャ（入力層（データステージ、 Data Vault 2.0では永続ステージング領域と呼ばれる）とプレゼンテーション層（データマート）、データ品質サービスとマスターデータサービスの処理など）、そしてモデルです。方法論では、ベストプラクティスの実装が定義されています。Data Vault 2.0は、ビッグデータやNoSQLなどの新しいコンポーネントを含めることに重点を置いており、既存モデルのパフォーマンスにも重点を置いています。古い仕様（大部分はここで文書化されています）は、データボールトのモデリングに重点を置いています。これは、書籍「Building a Scalable Data Warehouse with Data Vault 2.0」に記載されています。[13]
EDW および BI システムを今日のビジネスのニーズと要望に合わせて最新の状態に保つには、ベスト プラクティスとともに新しいコンポーネントを組み込んだ仕様を進化させる必要があります。
歴史
データボルトモデリングは、1990年代にダン・リンステッドによって考案され、2000年にパブリックドメインのモデリング手法として公開されました。データ管理ニュースレターに掲載された5部構成の記事では、データボルト手法の基本ルールが拡張され、説明されています。これらには、一般的な概要、[14]、コンポーネントの概要、[15] 、終了日と結合に関する説明、[16]、リンクテーブル、[17]、およびロード方法に関する記事が含まれています。[18]
この方法の別名（あまり使われないが）は「共通基礎統合モデリングアーキテクチャ」である。[19]
データボルト2.0 [20] [21]は2013年に登場し、ビッグデータ、NoSQL、非構造化、半構造化のシームレスな統合、方法論、アーキテクチャ、実装のベストプラクティスをもたらしました。
代替解釈
ダン・リンステッドによると、データモデルはニューロン、樹状突起、シナプスの単純な見方に触発（またはパターン化）されています。ニューロンはハブとハブサテライトに関連付けられ、リンクは樹状突起（情報のベクトル）、他のリンクはシナプス（反対方向のベクトル）です。データマイニングアルゴリズムセットを使用することで、リンクは信頼度と強度の評価でスコア付けできます。リンクは、現在存在しない関係についての学習に応じて、オンザフライで作成および削除できます。モデルは、使用され、新しい構造が入力されるにつれて、自動的に変形、適応、調整されます。[22]
もう 1 つの見方は、データ ボールト モデルは、エンタープライズのドメイン内の用語(ハブ) とそれらの間の関係 (リンク) を記述し、必要に応じて説明的な属性 (サテライト) を追加するという意味で、エンタープライズのオントロジーを提供するというものです。
データボルトモデルをグラフィカルモデルとして捉える別の方法があります。データボルトモデルは、リレーショナルデータベースの世界におけるハブとリレーションシップを備えた「グラフベース」のモデルを提供します。これにより、開発者はSQLを使用して、1秒未満の応答でグラフベースのリレーションシップを取得できます。
基本概念
Data Vault 2.0は、安定した識別子と変化する記述属性を分離する3つのコアコンポーネントにデータを整理します。[23]
- ハブ– コアビジネスコンセプトの一意のビジネスキーと、系統/監査のための最小限のメタデータを保存します。ソース間の統合ポイントとして機能します。[23]
- リンク– ハブ間の関係（多くの場合、多対多）をキャプチャします。参加しているハブキーは関係の粒度を定義します。[23]
- サテライト– ハブまたはリンクに関連付けられた記述属性とその履歴が含まれます。サテライトは追加のみ可能なため、すべての変更が保存されます（ディメンションモデルのタイプII履歴に似ています）。[23]
特殊なサテライトは時間的なセマンティクスをサポートします。例えば、リンク上の有効性サテライトは、関係がビジネス上有効であるとみなされる開始日と終了日を記録します。[23]
レイヤー
- Raw Vault – 最小限の変換で詳細かつ監査可能な履歴を保持するソース駆動型の統合レイヤー。[23]
- Business Vault – ビジネスルールとクエリ支援構造（PITやブリッジテーブルなど）を適用して下流の消費を容易にする派生レイヤー。[23]
次元モデルでの使用
実際には、データボルトは一般的に履歴統合層として機能し、スタースキーマ情報マートはRaw/Business Vaultから投影され、パフォーマンスの高い分析とより簡単なユーザーアクセスを実現します。[24] [25]
ハブ
ハブには、変更の可能性が低い一意のビジネスキーのリストが含まれています。また、ハブには、各ハブ項目の代理キーと、ビジネスキーの由来を説明するメタデータも含まれています。ハブの情報の説明属性（キーの説明など、複数の言語で記述される場合もあります）は、後述のサテライトテーブルと呼ばれる構造に保存されます
ハブには少なくとも以下のフィールドが含まれています: [26]
- 他の構造をこのテーブルに接続するために使用される代理キー。
- このハブのドライバーとなるビジネスキー。ビジネスキーは複数のフィールドで構成できます。
- レコード ソース。これを使用して、各ビジネス キーを最初にロードしたシステムを確認できます。
- オプションとして、手動更新 (ユーザー/時間) と抽出日に関する情報を含むメタデータ フィールドを持つこともできます。
2 つのシステムが同じビジネス キーを配信しているが、意味が異なる衝突が発生する場合を除き、ハブに複数のビジネス キーを含めることはできません。
ハブは通常少なくとも1つの衛星を持つ必要があります。[26]
ハブの例
これは、「Car」（H_CAR）と呼ばれる車を含むハブテーブルの例です。駆動キーは車両識別番号です
| フィールド名 | 説明 | 必須？ | コメント |
|---|---|---|---|
| H_CAR_ID | ハブのシーケンスIDとサロゲートキー | いいえ | 推奨されますが任意です[27] |
| 車両ID番号 | このハブを駆動するビジネスキー。複合ビジネスキーの場合は複数のフィールドを指定できます。 | はい | |
| H_RSRC | このキーが最初にロードされたときのレコードソース | はい | |
| LOAD_AUDIT_ID | ロード時間、ロード期間、行数などの監査情報を含むテーブルの ID。 | いいえ |
リンク
ビジネスキー間の関連付けまたはトランザクション（例えば、購入トランザクションを通じて顧客と製品のハブを相互に関連付ける）は、リンクテーブルを使用してモデル化されます。これらのテーブルは基本的に多対多の結合テーブルであり、いくつかのメタデータが含まれています
リンクは他のリンクにリンクすることで、粒度の変化に対応できます（例えば、データベーステーブルに新しいキーを追加すると、データベーステーブルの粒度が変化します）。例えば、顧客と住所の関連付けがある場合、商品と運送会社のハブ間のリンクへの参照を追加できます。これは「配送」というリンクになります。別のリンク内でリンクを参照することは、リンク間の依存関係が生じ、並列読み込みが困難になるため、推奨されません。別のリンクへのリンクは、別のリンクからハブへの新しいリンクと同じであるため、このような場合は、他のリンクを参照せずにリンクを作成することが推奨されます（詳細については、読み込み方法のセクションを参照してください）。
リンクは、ハブを構成するにはそれだけでは不十分な情報にハブをリンクすることがあります。これは、リンクに関連付けられたビジネスキーの1つが実際のビジネスキーではない場合に発生します。例えば、「注文番号」をキーとする注文書と、一意性を持たせるために半ランダムな数値（例えば「一意の番号」）がキーに設定された注文明細があるとします。後者のキーは実際のビジネスキーではないため、ハブにはなりません。しかし、リンクの粒度を正しく保証するためには、このキーを使用する必要があります。この場合、代理キーを持つハブは使用せず、ビジネスキー「一意の番号」自体をリンクに追加します。これは、そのビジネスキーが他のリンクやサテライトの属性のキーとして使用されることが全くない場合にのみ行われます。この構造は、Dan Linstedt氏（現在は閉鎖）のフォーラムで「peg-legged link（義足リンク）」と呼ばれています。
リンクには、リンクされているハブの代理キー、リンク自体の代理キー、そして関連付けの起源を示すメタデータが含まれます。関連付けに関する情報（時間、価格、金額など）の説明属性は、後述する サテライトテーブルと呼ばれる構造体に格納されます。
リンクの例
これは、車（H_CAR）と人（H_PERSON）の2つのハブ間のリンクテーブルの例です。リンクの名前は「ドライバー」（L_DRIVER）です
| フィールド名 | 説明 | 必須？ | コメント |
|---|---|---|---|
| L_DRIVER_ID | リンクのシーケンスIDと代理キー | いいえ | 推奨されますが任意です[27] |
| H_CAR_ID | カーハブの代理キー、リンクの最初のアンカー | はい | |
| H_PERSON_ID | リンクの2番目のアンカーである人物ハブの代理キー | はい | |
| L_RSRC | 最初にロードされたときのこの関連付けのレコードソース | はい | |
| LOAD_AUDIT_ID | ロード時間、ロード期間、行数などの監査情報を含むテーブルの ID。 | いいえ |
サテライト
ハブとリンクはモデルの構造を形成しますが、時間属性や記述属性は保持しません。これらはサテライトと呼ばれる別々のテーブルに保存されます。これらは、親ハブまたはリンクにリンクするメタデータ、関連付けと属性の起源を記述するメタデータ、および属性の開始日と終了日を含むタイムラインで構成されます。ハブとリンクがモデルの構造を提供するのに対し、サテライトはモデルの「中身」、つまりハブとリンクで捕捉されるビジネスプロセスのコンテキストを提供します。これらの属性は、案件の詳細とタイムラインの両方に関して保存され、非常に複雑なもの（すべてのフィールドがクライアントの完全なプロファイルを記述するもの）から非常に単純なもの（有効インジケータとタイムラインのみを持つリンク上のサテライト）までさまざまです
通常、属性はソースシステムごとにサテライトにグループ化されます。ただし、サイズ、コスト、速度、量、色などの説明的な属性は変化率が異なる場合があるため、変化率に基づいてこれらの属性を異なるサテライトに分割することもできます。
すべてのテーブルにはメタデータが含まれており、少なくともソース システムとこのエントリが有効になった日付が記述されており、データ ウェアハウスに入るデータの完全な履歴ビューが提供されます。
有効性衛星とは、リンク上に構築され、「対応するリンクが開始有効性と終了有効性を記録する期間を記録する」衛星である。[28]
サテライトの例
これは、車と人のハブ間のドライバーリンクにある「ドライバー保険」（S_DRIVER_INSURANCE）と呼ばれるサテライトの例です。このサテライトには、車と運転者との関係における保険に特有の属性が含まれています。例えば、運転者が主な運転手であるかどうか、この車と人の保険会社名（別のハブの場合もあります）、この車両とドライバーの組み合わせが関与する事故件数の概要などです。また、この関係が該当すると見なされるリスクカテゴリーのコードを含む、R_RISK_CATEGORYと呼ばれる参照テーブルへの参照も含まれています
| フィールド名 | 説明 | 必須？ | コメント |
|---|---|---|---|
| S_DRIVER_INSURANCE_ID | リンク上の衛星のシーケンスIDと代理キー | いいえ | 推奨されますが任意です[27] |
| L_DRIVER_ID | （代理）ドライバーリンクの主キー、衛星の親 | はい | |
| S_SEQ_NR | 1つの親キーに対して複数の有効なサテライトがある場合に、一意性を強制するための順序番号またはシーケンス番号 | いいえ(**) | たとえば、ハブコースがあり、コース名が属性であるが複数の異なる言語で表記されている場合に、このような状況が発生する可能性があります |
| S_LDTS | 親キーL_DRIVER_IDのこの属性値の組み合わせの有効期間のロード日（開始日） | はい | |
| S_LEDTS | 親キーL_DRIVER_IDのこの属性値の組み合わせの有効期間のロード終了日（enddate） | いいえ | |
| IND_PRIMARY_DRIVER | ドライバーがこの車の主運転手であるかどうかを示すインジケーター | 番号（*） | |
| 保険会社 | この車両とドライバーの保険会社名 | 番号（*） | |
| 事故件数 | このドライバーによるこの車両での事故件数 | 番号（*） | |
| リスクカテゴリーCD | ドライバーのリスクカテゴリ。これはR_RISK_CATEGORYへの参照です。 | 番号（*） | |
| S_RSRC | この衛星に最初にロードされたときの情報のレコードソース | はい | |
| LOAD_AUDIT_ID | ロード時間、ロード期間、行数などの監査情報を含むテーブルの ID。 | いいえ |
(*) 少なくとも 1 つの属性は必須です。 (**) 同じハブまたはリンク上の複数の有効な衛星の一意性を強制する必要がある場合、シーケンス番号は必須になります。
参照表
参照テーブルは、健全なデータ保管モデルにおいて不可欠な要素です。参照テーブルは、頻繁に参照される単純な参照データの重複保存を防ぐために存在します。より正式には、Dan Linstedtは参照データを次のように定義しています。
コードから説明を解決したり、キーを一貫した方法で変換したりするために必要と思われる情報。これらのフィールドの多くは「記述的」な性質を持ち、他のより重要な情報の特定の状態を記述します。そのため、参照データは生のData Vaultテーブルとは別のテーブルに保存されます。[29]
参照テーブルはサテライトから参照されますが、物理的な外部キーでバインドされることはありません。参照テーブルには規定の構造はありません。単純な参照テーブルから小規模なデータボールト、さらにはスター型まで、個々のケースに最適なものを使用してください。参照テーブルは履歴テーブルでも履歴なしでも構いませんが、自然キーを使用し、その場合は代理キーを作成しないことが推奨されます。[30]通常、データボールトには、他のデータウェアハウスと同様に、多数の参照テーブルがあります。
参照例
これは、車両の運転者に関するリスクカテゴリーの参照テーブルの例です。データボールト内のどの衛星からも参照できます。ここでは、衛星S_DRIVER_INSURANCEから参照します。参照テーブルはR_RISK_CATEGORYです
| フィールド名 | 説明 | 必須？ |
|---|---|---|
| リスクカテゴリーCD | リスクカテゴリーのコード | はい |
| リスクカテゴリー説明 | リスクカテゴリーの説明 | 番号（*） |
(*) 少なくとも 1 つの属性は必須です。
ロードプラクティス
データボルトモデルを更新するためのETLは非常に簡単です（データボルトシリーズ5 – ロードプラクティスを参照）。まず、すべてのハブをロードし、新しいビジネスキーの代理IDを作成する必要があります。これを行うと、ハブにクエリを実行すると、すべてのビジネスキーを代理IDに解決できるようになります。次のステップは、ハブ間のリンクを解決し、新しい関連付けの代理IDを作成することです。同時に、キーを代理IDに解決できるため、ハブに接続されているすべてのサテライトを作成することもできます。代理キーを使用してすべての新しいリンクを作成したら、サテライトをすべてのリンクに追加できます
ハブはリンクを介してのみ接続されているため、すべてのハブを並列にロードできます。リンクは直接接続されていないため、すべてのリンクを並列にロードできます。サテライトはハブとリンクにのみ接続できるため、これらも並列にロードできます。
ETLは非常に単純で、自動化やテンプレート化が容易です。問題は、他のリンクに関連するリンクでのみ発生します。これは、リンク内のビジネスキーを解決すると、別のリンクも解決する必要があるためです。この状況は複数のハブへのリンクと同等であるため、このようなケースをリモデリングすることでこの問題を回避できます。実際、これは推奨される方法です。[18]
データのロード中に技術的なエラーが発生しない限り、データはデータ ボールトから削除されることはありません。
データ保管庫と次元モデリング
データヴォールトのモデル化レイヤーは通常、データの保存に使用されます。クエリパフォーマンスが最適化されておらず、Cognos、Oracle Business Intelligence Suite Enterprise Edition、SAP Business Objects、Pentahoなどの一般的なクエリツールによるクエリも容易ではありません。[要出典]これらのエンドユーザーコンピューティングツールは、データが多次元モデルに格納されることを前提としているか、または好むため、通常は変換が必要です。
この目的のために、ハブとそれらのハブ上の関連サテライトをディメンションと見なし、リンクとそれらのリンク上の関連サテライトをディメンション・モデル内のファクト・テーブルとして表示することができます。これにより、ビューを使用してデータ・ボルト・モデルからディメンション・モデルのプロトタイプを迅速に作成できます。
データボルトモデルから（クレンジングされた）ディメンションモデルにデータを移動するのは比較的簡単ですが、その逆は、ディメンションモデルのファクトテーブルの非正規化の性質（データボルトの第3正規形とは根本的に異なる）を考えると、それほど簡単ではありません。 [31]
方法論
データボールト方法論は、SEI / CMMIレベル5のベストプラクティスに基づいています。CMMIレベル5の複数のコンポーネントを含み、シックスシグマ、総合的品質管理（TQM）、SDLCのベストプラクティスと組み合わせています。特に、スコット・アンブラーのアジャイル手法による構築と展開に重点を置いています。データボールトプロジェクトは、スコープ管理された短いリリースサイクルで行われ、2～3週間ごとに本番リリースを行う必要があります
データ ボールト方法論を使用するチームは、CMMI レベル 5 で期待される、反復可能で一貫性があり測定可能なプロジェクトに容易に適応できるはずです。EDW データ ボールト システムを流れるデータは、BI (ビジネス インテリジェンス) プロジェクトでは長い間欠けていた TQM ライフサイクルに従うようになります。
ツール
ツールの例：[説明が必要]
- データボルト4dbt
- 2150 データボルトビルダー
- アステラDWビルダー
- ウェアスケープ
- ヴォルトスピード
- オートメイトDV
参照
- アジャイルビジネスインテリジェンス - ビジネスインテリジェンスプロジェクトにおけるアジャイルソフトウェア開発の活用リダイレクト先の簡単な説明が表示されているページ
- ビル・インモン – アメリカのコンピューター科学者
- データレイク – 生の形式で保存されたデータのリポジトリ
- データウェアハウス – 知識の集中保管
- キンボールライフサイクル- アメリカのコンピュータ科学者ラルフ・キンボールリダイレクト先の簡単な説明が表示されているページが開発した データウェアハウス開発の方法論
- ステージングエリア – 使用前にアイテムを集める場所
- スター スキーマ- データ ボールト モデリングの主な代替手段
参考文献
引用
- ^ 『データウェアハウスをスーパーチャージする』74ページ
- ^ 次世代EDW
- ^ データボルト 2.0 によるスケーラブルなデータウェアハウスの構築、6 ページ
- ^ データウェアハウスをスーパーチャージする、21ページ
- ^ データウェアハウスをスーパーチャージする、76ページ
- ^ ポースビー、ヨハン。 「Rålager istället for ett strukturerat datalager」。www.agero.se (スウェーデン語) 。2023 年 2 月 22 日に取得。
- ^ ポースビー、ヨハン。 「データウェアハウスのためのデータモデラー」。www.agero.se (スウェーデン語) 。2023 年 2 月 22 日に取得。
- ^ データボルト2.0によるスケーラブルなデータウェアハウスの構築、11ページ
- ^ データボルト2.0によるスケーラブルなデータウェアハウスの構築、p. xv
- ^ 「データウェアハウスの概念：KimballとInmonのアプローチ」Astera . 2020年2月3日. 2024年10月2日閲覧。
- ^ 『ニュービジネススーパーモデル』用語集、75ページ
- ^ #datavault 2.0 の簡単な紹介
- ^ 「Data Vault 2.0によるスケーラブルなデータウェアハウスの構築[書籍]」www.oreilly.com . 2024年10月2日閲覧。
- ^ 「データボルトシリーズ1 – データボルトの概要」TDAN.com 2002年7月1日. 2024年10月2日閲覧。
- ^ 「データボルトシリーズ2 – データボルトコンポーネント」TDAN.com 2003年1月1日. 2024年10月2日閲覧。
- ^ データボルトシリーズ3 – 終了日と基本的な結合
- ^ Data Vault シリーズ 4 – リンクテーブル、パラグラフ 2.3
- ^ ab データボルトシリーズ5 – ロード方法
- ^ データウェアハウス入門、83ページ
- ^ #datavault 2.0 の簡単な紹介
- ^ Data Vault 2.0 発表
- ^ データウェアハウスをスーパーチャージする、5.20節、110ページ
- ^ abcdefg リンステッド、ダニエル; オルシムケ、マイケル (2015). Data Vault 2.0によるスケーラブルなデータウェアハウスの構築. モーガン・カウフマン. ISBN 9780128025109。
- ^ ハルトグレン、ハンス (2012). Data Vaultによるアジャイルデータウェアハウスのモデリング. ブライトン・ハミルトン. ISBN 9780615723082。
- ^ 「データウェアハウス・ツールキット 第3版」Wiley
- ^ ab Data Vault Forum、標準セクション、セクション3.0 ハブルール
- ^ abc Data Vault モデリング仕様 v1.0.9
- ^ 有効性衛星 - dbtvault
- ^ データウェアハウスをスーパーチャージする、パラグラフ 8.0、146 ページ
- ^ データウェアハウスをスーパーチャージする、段落8.0、149ページ
- ^ メルボルンヴォールト、2023年5月16日
出典
- リンステッド、ダン（2010年12月）。『データウェアハウスをスーパーチャージする』ダン・リンステッド著。ISBN 978-0-9866757-1-3。
- トーマス・C・ハマーグレン、アラン・R・サイモン（2009年2月）。『データウェアハウス入門 第2版』John Wiley & Sons. ISBN 978-0-470-40747-9。
- ロナルド・ダムホフ、リドヴィネ・ファン・アス（2008年8月25日）「次世代EDW - 真実の単一バージョンという考えを捨てる」（PDF）データベース・マガジン（DB/M）アレイ・パブリケーションズBV
- リンステッド、ダン. 「データボルトシリーズ1 – データボルトの概要」.データボルトシリーズ. データ管理ニュースレター. 2011年9月12日閲覧.
- Linstedt, Dan. 「データボルトシリーズ2 – データボルトコンポーネント」。データボルトシリーズ。データ管理ニュースレター。 2011年9月12日閲覧。
- リンステッド、ダン. 「データボルトシリーズ3 – 終了日と基本的な結合」.データボルトシリーズ. データ管理ニュースレター. 2011年9月12日閲覧.
- Linstedt, Dan. 「データボルトシリーズ4 – リンクテーブル」。データボルトシリーズ。データ管理ニュースレター。 2011年9月12日閲覧。
- リンステッド、ダン. 「データボルトシリーズ5 – ロード方法」.データボルトシリーズ. データ管理ニュースレター. 2011年9月12日閲覧.
- Kunenborg, Ronald. 「Data Vault Rules v1.0.8 チートシート」（PDF） . Data Vault Rules . Grundsätzlich IT . 2012年9月26日閲覧。v1.0.8 のルールを反映したチートシートと、v1.0.8 のルールに関するフォーラムからの追加の説明。
- Linstedt, Dan. 「Data Vault Modeling Specification v1.0.9」. Data Vault Forum . Dan Linstedt. 2012年11月30日時点のオリジナルよりアーカイブ。 2012年9月26日閲覧。
- Linstedt, Dan. 「Data Vault Loading Specific v1.2」DanLinstedt.com . Dan Linstedt. 2014年1月3日時点のオリジナルよりアーカイブ。 2014年1月3日閲覧。
- Linstedt, Dan. 「#datavault 2.0 の簡単な紹介」DanLinstedt.com . Dan Linstedt. 2014年1月3日時点のオリジナルよりアーカイブ。 2014年1月3日閲覧。
- リンステッド、ダン。「Data Vault 2.0 発表」。DanLinstedt.com 。ダン・リンステッド。2012年8月21日時点のオリジナルよりアーカイブ。 2014年1月3日閲覧。
- オランダ語の情報源
- Ketelaars, MWAM (2005-11-25). 「Datawarehouse-modelleren met Data Vault」.データベースマガジン (DB/M) (7). Array Publications BV : 36–40
- バーハーゲン、K.フライコルテ、B. (2008 年 6 月 10 日)。 「Relationeel 対 Data Vault」。データベースマガジン(DB/M) (4)。アレイ出版物 BV: 6–9。
文献
- パトリック・キューバ：データボルトの達人。データボルト構築の実践ガイド。Selbstverlag、Ofne Ort 2020、ISBN 979-86-9130808-6
- ジョン・ジャイルズ：冷蔵庫の中の象。ビジネス中心のモデル構築によるデータ保管庫成功へのガイド付きステップ。Technics、バスキングリッジ、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。
- ダニエル・リンステッド著『データウェアハウスをパワーアップ！データヴォールトを実装するための貴重なデータモデリングルール』リンステッド社、セント・オールバンズ、バーモント州、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のホームページ
