2

皆さんに質問があります。最初に既存の同じ質問を検索しましたが、関連するものしか見つかりませんでしたが、私の質問に固有のものではありませんでした。だからここに行く：

ディメンション テーブルに主キーがあることは重要ですか? 私がデータ ウェアハウスを設計した方法は、正規化されたデータ ストアで代理キーを管理したためです。次に、サロゲート キーが Dim テーブルに渡されます。ソース システムからの更新は、最初に NDS に反映されます (タイプ 1 またはオーバーライド)。したがって、基本的に、正規化されたデータ ストアの履歴値は追跡しません。ただし、次元データ ストアの変更は追跡しています。

このため、dim テーブルの代理キーは DB によって管理されません。ソース システムからの変更がある場合、同じ代理キーを持つ新しい行、選択したタイプ 2 の変更のフィールド/列を除くすべてが同じです。

ディム テーブルには主キーがないため、ファクト テーブルには FK 制約はありません。データ マート (PK/FK 制約のない Fact テーブルと Dim テーブル) を使用する場合、これはデータ ウェアハウスのパフォーマンスにどのように影響しますか?

サンプルデータのスクリーンショットは次のとおりです。

http://i69.photobucket.com/albums/i47/boxingpics/dim_customer.jpg

これでいいですか？

4

1 に答える 1

1

はい、ディメンション テーブルに主キーが必要です。

NDS は、異種のソース システム全体でエンティティを管理するために代理キー デザイン パターンを使用しているだけだと思います。これはそれほど珍しいことではありません...発生する問題のいくつかをカバーしている Thomas Kejser による良い投稿があります。

つまり、NDS がタイプ 1 の変更のみを追跡し、データ マートでタイプ 2 (履歴) の変更を追跡する必要がある場合は、追加の代理キーをミックスに追加する必要があります。

于 2012-09-09T13:01:00.340 に答える