ファクトテーブルの非数値属性（データソースを追跡するため）？
キンボールの方法論に従って、スタースキーマを使用してデータウェアハウスを作成しています。ルールの1つは、ファクトテーブルに数値のみを配置することです。
ファクトが挿入されたデータのソースを追跡するために、ファクトテーブルに「id」を配置することを検討しています。ユーザーはさまざまな方法でデータをアップロードできます。ユーザーがデータのアップロードを間違えて編集したいというユースケースをサポートする必要があります。したがって、アップロードされたすべてのデータにジョブIDと行IDを配置し、生データをアップロードしたままにすることを検討しています（ステージング領域からのETLの前）。このようにして、ユーザーはアップロードのログを表示し、必要に応じてそれらを編集して正しいデータに置き換えることができます。
これらのIDをファクトテーブルに入れるのは本当に悪いですか？別の方法は、それらを特別な追跡ディメンションに配置することです。ただし、このディメンションにはファクトテーブルの行ごとに1つの行があるので、ファクトテーブルに配置するのは意味がありませんか？
私は通常、ファクトテーブルにビジネスキーを持っているので、質問があればソースシステムまで簡単に追跡できます。通常、ファクトテーブルの粒度がビジネスキーと同じになるように、一意の制約を設定します。
私が思いついた解決策はこれです：
ファクトテーブルの既存のデータを上書きするには、上書きするデータを日付で特定するだけです。この特定のデータモデルでは、各日付に最大1つのファクトエントリを含めることができます。
これは、ファクトテーブルにビジネスキーを配置するよりもうまく機能すると思います。データモデルが進化するにつれて、サポートするデータソースが増えるため、それらすべてにビジネスキーが必要になる可能性があります。
また、キンボールの本のように「監査」ディメンションを追加します。