DWH 環境における代理キーの一般的な概念を理解しています。しかし、私が理解できず、情報を見つけることができなかった2つの側面があります。
- 代理キーがDWH 全体で一意であること、または1 つの Dimension で一意であることはよくあることですか?
- 階層を持つディメンションがある場合、その階層は代理キーの生成に影響しますか?
DWH 環境における代理キーの一般的な概念を理解しています。しかし、私が理解できず、情報を見つけることができなかった2つの側面があります。
1) 代理キーは 1 つの行に固有です。行内のすべてのセル間の関係の共通ハンドルとして使用されます。データの保存方法が原因で、行内のセル間の関係を推測するために代理キーが厳密に必要というわけではありません。ただし、行がエンティティ (テーブル) 内のカウント可能な ID (行) を表している場合 (データベースが正規化されている場合)、単一の代理キー (通常は主キー) を参照する方が、参照を維持するよりも簡単です。主キーのすべての参加者に。たとえば、1 つのコンパクトな列でインデックスを維持する方が、行全体で維持するよりも簡単です。
実際、テーブルの代理キーには別の用途があります。多くの場合、データは多くのソースから結合されるため、複合主キー (複数の列を結合して各行を一意に識別する) の問題や、ビジネス キーの重複 (さまざまなソースから取得したキー) の問題に遭遇する可能性があります。ソースシステム)。代理キーはルックアップに使用されるため、コンパクトであることが重要です。増分整数または固定長ハッシュを使用し、ソースからのビジネス キーを別の列に保持します。
2) ディメンションと階層の管理に使用しているソフトウェアがわからないため、この質問への回答は困難です。これは物事に大きく影響します。典型的な非正規化された Kimball アーキテクチャでは、ディメンション テーブルで、代理キーを使用して一意の行を参照します。寸法表で。複数の階層を持つディメンション テーブルでは、この意味が少しわかりにくい場合があります。サロゲート キーは、カーディナリティ (メンバー数) が最も高い階層でのみ真に一意になります。これが、ディメンション テーブルに含まれる行数を決定するためです。そのため、キーはディメンション テーブルに固有であり、かつその中の階層の 1 つ (メンバー数が最も多い階層) に固有であることが実践されます。これに階層のバージョン管理 (緩やかに変化するディメンション) を追加すると、代理キーの正確な意味が誤解される可能性があります。
注/暴言 : 私は一般的に、1 つのディメンション テーブルに複数の階層があるという考えに非常にぞっとします。確かに、ファクト テーブル内のディメンション参照の数は減りますが、欠点もあります。ディメンション テーブルの非正規化 (見苦しい重複) には、いくつかの結果があります。そのうちの 1 つは、ディメンション テーブルで結合する際の二重カウントのリスクです。これは、多くの場合、使用するソフトウェア パッケージによって修正されます (または見過ごされます)。値が同じかどうかを確認し、それらを合計して、同じ場合はカウントを減らします。しかし、これは異常をカウントし、エラーを合計する一般的な原因であり、将来的には非常に汚いハックによってのみ処理できます。そのうちのかなりの数を見てきました。