データウェアハウスのサロゲートキーの管理

Question

データウェアハウスを構築したいが、私のファクトテーブルの主キーとしてサロゲートキーを使用したい。しかし、問題は、私の場合、事実テーブルを更新する必要があるということです。

最初の質問は、ソースシステムのナチュラルキーの対応する自動生成サロゲートキーを見つける方法です。私は、自然とサロゲートキーの間の対応関係を格納するルックアップテーブルに言及しているいくつかの答えを見てきましたが、どのように正確に実装されているのか分かりませんでした。このテーブルを格納する場所：データウェアハウス自体、または他の場所？

2番目の質問もあります。ソース・システムには、ファクトの代理キーがすでに含まれていますが、UUIDデータ・タイプは16バイトです。そして事実の数は最大整数値（4バイト）を超過する可能性は非常に低いです。 ETLを単純化するためにソースシステムによって提供されるUUIDを使用するか、より複雑なETLを実行し、パフォーマンスを向上させるために自分の整数代理キーを実装する必要がありますか？

Answer 1

質問のようです： 行の最初の読み込み時にデータウェアハウスに代理キーを生成する場合、後続の読み込みでキーがすでに生成されているかどうかを確認するにはどうすればよいですか？ルックアップテーブルを作成する必要がありますか？

注：データ・ウェアハウス・ターゲット表のソース・システムのキーを可能な限り含めてください。必要と思わない場合もあります。 ETLの問題のトラブルシューティングには非常に役立ちます。

2つの直接的なオプション：

1.ターゲットテーブルに対して直接ルックアップを実行します（パフォーマンスは大きなテーブルで問題になることがあります）。

2. ETLプロセスでのみ使用される（データウェアハウスに格納されている） "etlステージングルックアップ"テーブルを作成します。これはより柔軟なオプションですが、ETLに追加のステップを追加します。

Answer 2

残りはすでに回答済みだと思います。私はサロゲートキーの管理と維持について私に2セントを与えるつもりです。

私はTeradataの私の時間の間に代理キーをたくさん使っていました。サロゲートキーについて私が長年にわたって学んたベストプラクティスをいくつか紹介します。あなたが唯一の特定のAPI あなたのケースで（承認されたマスター・ソースからのサロゲートキーを生成

1. 。多くないAPIが に同じドメイン値を生成許されるべきである。あなたのドメインのマスター として動作するものを選んでくださいたとえば、顧客番号は通常 システムから来ており、請求システムのマスタではない可能性があります。
2. &を生成します。これは実際にルックアップテーブルに格納します（ Customer_SGKとします）。一般に、これらのサロゲートキーテーブルは、inmonまたはkimbalのいずれかの方法で 最終LDM/PDMの一部ではありません。これらの は、同じデータベースサーバー内ではなく、技術的な メタデータスキーマ内に存在します。あなたが維持するために、各マスター・ソース （source1_customerNO、source2_customerNO）およびタイムスタンプごとに代理キー列（例えば CUSTOMER_ID）、ソースの自然キー列（複数可）を持っているだろう、このようなルックアップテーブルでは、そのスキーマ「My_Tec_Schema」
3. を呼ぶことにしましょうa このキーが生成された時刻。
4. あなたのPKはCustomer_IDです。これはこの列で一意ではない可能性があります。使用するデータストレージ技術によっては、一意または一意ではない一次インデックス/キーとして分類する必要があります（たとえばTeradataではNUPI）。

5. 2つの異なるソースシステムからの異なる2つのナチュラルキーに同じ顧客IDをロードしている間に、同じ顧客を意味する場合があります。

6. このルックアップテーブルを使用すると、ETL プロセスの最初のものをステージテーブル/ソースから読み込み（キーを生成する） することができます。次に、左外部結合をルックアップ テーブルからロードして代理キーを取得し、それをファクトテーブル にロードし、あなたのナチュラルキーもまたロードします。 （あなたは常に を持っていることが多いので、ほとんどの場合、あなたのファクトテーブルに孤児ができます。 唯一の速い&信頼できる方法は、その状況を回復することです あなたのファクトテーブルにあなたの自然なキーを持ち、PKまたはPI完全なテーブルではなく、 スキャン）

7. あなたは常に 経由でプレゼンテーション層ビュー（ アプリケーション&ユーザーを消費して使用されるビューをお使いのファクトテーブルのあなたの自然キーを隠すことができ非常に迅速であるインデックス ベースの更新操作ETL目的のテーブルを維持しながら/ 技術者のみ）
8. 自動番号生成手法を使用しているため、ある環境から別の環境にデータを移行している間、およびメジャーリリース中に運用データを移行しているときには、特に注意を払わなければなりません。 （あなたは の衝突を受けたくない）

私は代理キーで何度もやり直すことができます。このハイレベルの概要を読んでいる特定の質問をしてください。私は助けてうれしい。