4

データ ウェアハウス ディメンションで代理キーを使用する正当な理由があることは理解しています。それでも、それらをファクト テーブルの外部キーにリンクする方法がわかりません。ファクト テーブルには、ETL 中に抽出された自然キーのみがあります。代理キーは、元のデータベース テーブルには存在しません。これに関する提案はありますか？ありがとうございました

4

3 に答える 3

5

以下にいくつかの「参照」リファレンスがあります。これはスタック オーバーフローに関する私の最初の回答であるため、リンクを提供するのに十分な評価ポイントがありません。ウィキペディアでこれらの用語を調べると、私よりも雄弁に説明されています。

私が使用したデータ ウェアハウスでは、通常、さまざまなディメンションを参照する代理キーをファクト テーブルに格納します。実際、特別な状況 (縮退ディメンションなど) を除いて、ソース システムからの自然キーをファクト テーブルに格納することは避けています。これにはいくつかの理由があります。

  • 結合の効率 - ソース システムによっては、単純な整数キーを使用しない場合があります。代理キーを使用すると、この複雑さが軽減され、1 つの列の整数結合を処理するだけで済むため、データ ウェアハウスのクエリ パフォーマンスが向上します。
    • ソース システムからのファクト テーブルの抽象化。ファクト テーブルが特定のソース システム (またはソース システムのバージョン) よりも長く存続する場合や、異なる自然キーを持つ異なるソース システムからファクトが取得される場合があります。自然キーの設計に関係なく、ファクト テーブルとディメンション テーブルの関係は変わりません。
    • 正確で効率的なポイント イン タイム ファクト - ディメンション内の属性の履歴が重要な場合は、代理キーを使用して、ディメンション行の履歴コピーを保存し、修正バージョンをファクト テーブル行に添付できます (Slowly を参照)。寸法の変​​更、特にタイプ 2)
    • ディメンションは、複数のソース システムの複数のファクト テーブルで使用されるか、複数のソース システムから統合される可能性があります。この場合、ソース システムの自然キーとディメンションの代理キーの間に単純な関係はありません (適合ディメンションを参照)。
    • 不明 - 自然キーが NULL である、無効な値である、または何らかの奇妙な事実がある場合があります。不明、無効、まだ発生していない、または適切なものを表す特別な行をディメンション テーブルに 1 つ以上作成することで、その状態を表し、データベース内の参照整合性を維持することができます。(技術的には、NULL の値をキーにすることはできませんが、一部のデータベース エンジンでは、データ ウェアハウスのパフォーマンスと使いやすさを犠牲にして、NULL を使用できます)
    • 確かに大事なことを忘れてる…

一般に、ファクト テーブルをロードする変換フェーズでは、ソース システムからの自然キーの代理キーを検索し、代理キーを自然キーの代わりにファクト テーブルに格納します。どのプラットフォームを使用しているかはわかりませんが、ほとんどのデータベース プラットフォームで JOIN を使用してこれを行うことができます。私は、Microsoft SQL Server プラットフォームで SSIS ルックアップを頻繁に使用しています。

于 2015-12-14T16:05:59.003 に答える
2

代理キーの割り当ては、ファクト テーブルをロードする ETL プロセスで実装されます。

製品コード ABSFG-QXYX-12673726 などの自然キーは、専用のマッピング テーブルを使用して、通常は 1238 などの整数の代理キーにマップされます。

代理キーは便利で、次のシナリオで展開する必要があります。

  • 自然キーは変更可能です。つまり、自然キーの変更にもかかわらず、同じ代理キーでレポートする必要があります

  • 自然キーは再利用できます。つまり、同じ自然キーを取得できますが、新しいエンティティとして報告する必要があります。

  • 自然キーは扱いにくいです。たとえば、格納、結合、または並べ替えで問題が発生する可能性のある極端に長いハッシュ コードです。

サロゲート キーの使用法を厳しく検討する必要があるユース ケースがいくつかあります。

  • 自然キー (例: ソース システムから抽出されたキー) は既に代理されています (例: シーケンスで生成されたキー)

  • ソースシステムは、自然キーに関する追加情報(変更または再利用情報など) を提供できません。つまり、代理キーは事実上、自然キーの 1:1 マッピングになります。

  • 特にファクト テーブルが時間でレンジ パーティション化されている場合は、時間ディメンションに代理キーを使用しないでください (代理キーはレンジ パーティションのプルーニングを無効にするため)。

代理キーにも欠点があります

  • ETL プロセスでのマッピングが必要です (パフォーマンス)。

  • 最終レポートでは、自然キー (パフォーマンス) へのバックマッピングが必要になる場合があります。

  • 一貫性 – 「不明な」自然キーが表示された場合、代理キーへのマッピングが失敗するケースを処理する必要があります。ファクト レコードを拒否する必要がありますか、それとも (不完全な) マッピング テーブルの問題ですか?

  • もちろん、代理キーのマッピングにおける ETL エラーは問題につながる可能性があります…</p>

サロゲート キーを使用するのには十分な理由がありますが、サロゲート キーを使用しないのにも十分な理由があります。ソース システムからのインターフェイスを常に注意深く調べ、各ディメンション キーについて、代理キーを使用する利益がコストより高いかどうかを確認する必要があります。

于 2015-12-14T17:22:16.620 に答える
2

「ファクト テーブルの外部キーにそれらをリンクする方法」という質問に厳密に答えるには、最初に代理キーを割り当ててディメンションをロードし、次にビジネス キーでディメンションを検索してファクトをロードし、代理キーを見つけて使用する必要があります。事実を保存します。または、遅れて到着するディメンションの場合、ファクトの読み込み時にビジネス キーでディメンション メンバーが見つからない場合は、ビジネス キーを使用してディメンション メンバーを作成し、割り当てられた代理キーを使用します。後で、ディメンション メンバーが DWH に到着したときに、その中の追加の属性を更新するだけです。

実用的な観点から、ほぼリアルタイムの DWH が必要ない場合、または DWH を 1 日に 2 回 (たとえば夜間と昼食時など) だけ更新し、最初から再読み込みするのに数分しかかからない場合、およびメインのファクト テーブルに数百万のレコードしかない場合は、代理キーを気にする必要はありません。実際には、これは、非常に大きなワークロードと何百万ものファクトがある場合に適しています。この記事https://technet.microsoft.com/en-us/magazine/2008.04.dwperformance.aspxを読むと、洞察を得ることができます。

大規模な並列 DWH や Hadoop テクノロジなど、非常に大きな DWH を利用する場合は、代理キーをハッシュ キーに変更して、データ移動を最小限に抑え、データ スキューを回避し、バランスの取れた実行を提供する必要があります。

于 2015-12-14T22:13:02.910 に答える