0

タイトルがわかりにくいかもしれないので、現在の問題点を紹介したいと思います。

次の状況を想像してください。システムはデバイスの問題を保存します。これは資格のある作業者が修正する必要があります。テーブル「問題」があります：

  • PKとしてのID
  • workerid FK
  • 問題が解決したか未解決かを示すステータス
  • 推定完了時間
  • 実際の完了時間

およびその他の列。また、「問題」を保存し、それらの「労働者」のパフォーマンス（主に労働時間）を説明するデータウェアハウスもあります。

ETLプロセス中の最大の問題は、「未解決の問題」です。私には2つの可能性があります：

a）解決された「問題」のみを処理し、完了するまで未解決のままにしてから、完了するまで待って処理します。ただし、このタスクはレポートに含まれません。これは、完了するまでに時間がかかりすぎる可能性があり、ビジネスの側面で重要になる可能性があります。

b）解決済みの問題と未解決の問題の両方を処理します。ファクトテーブルのPKはissueIdとstatusである可能性があります。しかし、それから私は奇妙で分析するのが難しいかもしれないほとんど同じ問題を保存します。

これは一般的な状況ですか？これらの2つの可能性のどちらがより合理的だと思われますか？または、おそらくこれを行うための他のより良い方法がありますか？

4

1 に答える 1

1

問題ディメンションが必要なようで、そのディメンションはステータス列を保持します。事実の変更にはいくつかの問題があります。

  1. ファクト テーブルのステータス列を x 分ごとに更新するスケジュールされたプロセスをセットアップする必要があります。キューブの処理がより困難になり、ブロックが発生する可能性があり、変更の追跡が困難になるため (ステータスがいつ、誰が、なぜ変更したのか?)、ファクト テーブルを更新しないように常に心がけています。さらに、SQL 2012 にアップグレードし、列ストア インデックス (スター スキーマ クエリのパフォーマンスに革命をもたらした) を使用する場合、列を直接更新することはできません。
  2. 寸法は時々変更されることが予想されます。事実はそうではありません。ステータスがディメンションにある場合は、変更の追跡も簡単に設定できます。ゆっくりと変化する次元を調べます。
于 2012-09-03T21:54:03.607 に答える