ファクトテーブルの処理は何ですか？

ファクトテーブルには、複数の外部キー（ディメンションテーブルごとに1つ）と、これらのディメンションを使用するメジャーごとの列を含む複合主キーが含まれます。

すべてのデータステージングプロセスには、ファクトテーブルの各ディメンションについて、受信ファクトテーブルレコードの本番IDをデータウェアハウスの代理キーに置き換える手順を含める必要があります。他の処理、計算、および再構築も必要になる場合があります。

ウェアハウスでは、参照整合性（RI）により、ファクトテーブルの外部キーごとに、同等のディメンションテーブルにエントリが続くことが定義されます。製品番号323442のファクトテーブルに販売がある場合は、同じ番号の製品を製品ディメンションテーブルに含める必要があります。そうしないと、何を販売したかわかりません。存在しないと思われる商品のセールがあります。

サロゲートキーの統制された一貫した必要性は、抽出ロジックが常に2種類のサロゲートキールックアップを実行することを定義します。まず、変更されたディメンションレコードに遭遇し、ゆっくりと変更されるディメンション手法タイプ2を使用するたびに、新しい代理キーを作成する必要があります。

これは、ディメンションレコードの不定期の変更を処理するための主要な主力手法です。変更されたアイテムの新しいディメンションレコードを作成し、それに新しい代理キーを割り当てる必要があります。この新しいレコードで元のレコードと異なる唯一の属性は、代理キーと、変更された説明をトリガーした1つまたは複数のフィールドです。

2番目の種類の代理キールックアップは、ファクトテーブルレコードが処理されているときに発生します。参照整合性を維持するために、常に最初にディメンションレコードの更新を完了することを忘れないでください。このように、ディメンションテーブルは常に主キーの正当なソースです。この2番目の種類のサロゲートキールックアップでは、ファクトテーブルレコードのプロダクションキーをサロゲートキーの適切な現在の値に置き換える必要があります。

すべてのファクトテーブル生成キーが代理キーに置き換えられると、ファクトレコードをロードする準備が整います。ファクトテーブルレコードのキーは、それぞれのディメンションテーブルへの適切な外部キーとして選択されており、ファクトテーブルはディメンションテーブルの参照整合性を備えていることが保証されています。

しかし、この状況で妄想することは価値があります。このセクションで説明したすべての高度な管理では、実際のデータベースをロードする前に参照整合性を設定します。 1つ以上のディメンションテーブルの読み込みに失敗したり、ディメンションキーの値に応じてファクトレコードがまだ存在する場合にディメンションレコードを削除するなど、他の管理上のミスを犯したりすることで、参照整合性を破壊する可能性があります。