データ保管庫のモデリング

2 つのハブ（青）、1 つのリンク（緑）、4 つのサテライト（黄）によるシンプルなデータ保管庫モデル

Data vault は環境の変化に対処するため、（頻繁に変異しない）ビジネス鍵を分離しようと試みました。ビジネス・エンティティを一意に識別するため）およびそれらのビジネス・キー間の関連付けは、それらのキーの記述属性から。

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

HubsEdit

ハブは、変更する傾向が低い一意のビジネス・キーのリストを含みます。ハブはまた、各ハブ項目のサロゲートキーとビジネスキーの起源を記述するメタデータを含んでいます。

ハブには少なくとも次のフィールドがあります。

サロゲートキー（他の構造をこのテーブルに接続するために使用）
ビジネスキー（このハブのドライバ）
。ビジネス・キーは複数のフィールドで構成できます。
レコード・ソースは、どのシステムが各ビジネス・キーを最初に読み込んだかを確認するために使用できます。
オプションで、手動更新（ユーザー/時間）および抽出日についての情報を持つメタデータ・フィールドも持つことができます。

ハブは複数のビジネスキーを含むことはできません。ただし、2つのシステムが同じビジネスキーを配信しているが、異なる意味を持つ衝突がある場合は例外です。

ハブは通常少なくとも1つのサテライトを持つ必要があります。

Hub exampleEdit

これは「車」（H_CAR）という車を含むハブ・テーブルの例です。 7912>

このハブのドライブビジネスキーです。複合ビジネスキーの場合、複数のフィールドを指定可能

フィールド名	説明	必須?	Comment
H_CAR_ID	ハブのシーケンス ID および代理キー	なし	推奨だがオプション
VEHICLE_ID_NR	Yes
H_RSRC	最初にロードしたときのこのキーのレコードソース	Yes
LOAD_AUDIT_ID	ロードの時間、期間、ライン数など監査情報のテーブルへのIDです。	No

LinksEdit

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

リンクは、粒度の変更 (たとえば、データベーステーブルに新しいキーを追加するとデータベーステーブルの粒度が変わる) に対処するために、他のリンクにリンクすることができます。たとえば、顧客と住所の間に関連付けがある場合、製品と輸送会社のハブの間のリンクへの参照を追加することができます。これは、「配送」というリンクになる可能性があります。あるリンクを別のリンクで参照することは、リンク間に依存関係が生じ、並列ロードが困難になるため、悪い習慣と考えられています。他のリンクへのリンクは、他のリンクからのハブを含む新しいリンクと同じなので、このような場合は、他のリンクを参照せずにリンクを作成することが望ましい解決策です (詳細については、ロードの実践のセクションを参照してください)。これは、リンクによって関連付けられたビジネスキーの 1 つが実際のビジネスキーでない場合に発生します。例として、「注文番号」をキーとする注文書と、一意にするために半乱数でキー設定された注文行を考えてみます。例えば、”ユニークナンバー “とします。後者のキーは実際のビジネスキーではないので、ハブにはならない。しかし、リンクの正しい粒度を保証するために、これを使う必要がある。この場合、代理キーによるハブは使用せず、ビジネスキーの「固有番号」そのものをリンクに追加する。これは、そのビジネス・キーが他のリンクやサテライトの属性のキーとして使われる可能性がない場合にのみ行われる。

リンクには、リンクされているハブの代理キー、リンクの代理キー、および関連付けの起源を記述するメタデータが含まれます。関連付けの情報（時間、価格、金額など）の記述属性は、後述するサテライトテーブルと呼ばれる構造体に格納されます。

リンク例編集

これは車（H_CAR）と人（H_PERSON）の二つのハブの間のリンク・テーブルの例です。リンク名は “Driver”(L_DRIVER)です。

推奨だがオプション

車のハブに対する代理キーです。リンクの最初のアンカー

フィールド名	説明	必須?
L_DRIVER_ID	シーケンス ID およびリンクの代理キー	なし
H_CAR_ID	Yes
H_PERSON_ID	人物ハブの代用キー。リンクの2番目のアンカー	Yes
L_RSRC	最初にロードしたときのこの関連付けのレコードソース	Yes
LOAD_AUDIT_ID	監査情報テーブルのIDです。ロード時間、ロード期間、行数など。	No

SatellitesEdit

ハブとリンクはモデルの構造を形成しますが、時間属性はなく、記述属性も持ちません。これらはサテライトと呼ばれる別のテーブルに格納される。これらは、親ハブやリンクにリンクするメタデータ、関連や属性の起源を記述するメタデータ、属性の開始日と終了日を持つタイムラインから構成される。ハブとリンクがモデルの構造を提供するのに対し、サテライトはモデルの「肉」、つまりハブとリンクで捕捉されるビジネス・プロセスのコンテキストを提供する。これらの属性は、問題の詳細とタイムラインの両方に関して格納され、非常に複雑なもの（クライアントの完全なプロファイルを記述するすべてのフィールド）から非常に単純なもの（有効なインジケータとタイムラインのみを持つリンク上のサテライト）まで、さまざまです。しかし、サイズ、コスト、速度、量、または色などの記述的な属性は異なる速度で変化することがあるため、これらの属性をその変化率に基づいて異なるサテライトに分割することも可能です。

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

サテライトの例編集

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

Comment S_DRIVER_INSURANCE_ID シーケンスID、リンク上の衛星の代理キー無し推奨だがオプション L_DRIVER_ID

（代理）運転リンク用の主キー。サテライトの親

Yes S_SEQ_NR 順序またはシーケンス番号、一つの親キーに対して複数の有効なサテライトがある場合に一意性を強制します No（**）

例えばハブCOURSEがあってコース名が属性ですが複数の異なる言語がある場合、このことが起こる可能性があります。 S_LDTS Load Date (startdate) 親キー L_DRIVER_ID

の属性値のこの組み合わせの有効性について

Yes S_LEDTS 親キーL_DRIVER_ID

の属性値の組み合わせの有効性を示すロード終了日（enddate）

＜6651＞＜9914＞

IND_PRIMARY_DRIVER 親キーの属性値が有効かどうかを示すインジケータです。ドライバーはこの車の主なドライバーですいいえ (*) INSURANCE_COMPANY この車とこのドライバーの保険会社名いいえ (*) NR_OF_ACCIDENTS このドライバーによるこの車両の事故件数なし (*) R_RISK_CATEGORY_CD

ドライバーのリスクカテゴリを示します。 R_RISK_CATEGORY

いいえ (*) S_RSRC この衛星の情報を最初にロードしたときのレコードソースはい LOAD_AUDIT_ID 監査の情報のテーブルへの ID です。ロード時間、ロード期間、行数など。 No

（*）少なくとも 1 つの属性は必須です。（**）シーケンス番号は、同じハブまたはリンク上の複数の有効な衛星の一意性を強制するために必要な場合は、必須となります。これは、頻繁に参照される単純な参照データの冗長なストレージを防止するために存在します。より正式には、Dan Linstedt は参照データを次のように定義します。

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

参照テーブルはサテライトから参照されますが、物理的な外部キーでバインドされることはありません。単純なルックアップテーブルから小さなデータ保管庫、あるいは星型まで、特定のケースで最適なものを使用します。単純なルックアップテーブルから小さなデータ保管庫、さらにはスターまで、そのケースに最適なものを使用する。履歴があってもなくてもよいが、その場合は自然キーにこだわり、代理キーを作らないことが推奨される。

Reference exampleEdit

これは、自動車の運転者のリスクカテゴリを持つ参照テーブルの例です。データ保管庫内のどの衛星からも参照できます。ここでは、衛星S_DRIVER_INSURANCEから参照することにします。参照テーブルはR_RISK_CATEGORY.7912>

について。

フィールド名	説明	Mandatory?
R_RISK_CATEGORY_CD	リスクカテゴリのコード	はい
RISK_CATEGORY_DESC	リスクカテゴリの説明	なし (*)

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