sql - ディメンションの属性としての代理キー

Question

データ モデリングでは、ディメンションが別のディメンションへの代理キーを属性として持つことは許容されますか?それとも、これは常にビジネス キーであるべきですか?

部門番号を属性として持つ項目ディメンションがあります。また、Department ディメンションもあります。Item ディメンションが SK を Department ディメンションまたは単にビジネス キーに保持することは許容されますか?

Answer 1

通常、自然キーと代理キーの両方を外部キーとしてテーブルに含めることは避けます。これは冗長であり、データの不整合につながる可能性があるためです。例: 誰かが自然キーを更新し、代理キーも更新するのを忘れています。

ただし、リクエストにタグを付けたデータ ウェアハウスでは、冗長性はそれほど問題とは見なされません。通常、大量の挿入、更新、および削除を行うトランザクション処理システムがあり、次にデータ ウェアハウスがあります。データ ウェアハウスは、すべてのデータを処理システムから美しく配置され、上記のような更新はありません。データが重複している場合、誰が気にしますか? これにより、データ アクセスが簡素化されます。従業員と部門の結合を、すべての部門データが冗長なテーブルとして保存することもできます。データ ウェアハウスとは、レポート作成を容易にするために、データに簡単かつ迅速にアクセスすることです。冗長な外部キーは、データ ウェアハウスでは問題ありません。