0

簡単なシナリオ：「問題」（コスト、作業時間など）に関する情報を含むデータウェアハウスを作成したいと思います。問題には、時間の経過とともに変化する可能性のあるステータスもあります。そこで、各問題を説明するissueRealizationというファクトテーブルを作成しています。

私の質問は、ディメンションとファクトテーブルの間に1対1の関係を与える「問題」ディメンションを作成する必要があるかどうかです。または、Issueディメンションをステータスなどの最小ディメンションに分割する必要がありますか？

4

1 に答える 1

4

問題のステータスの追跡は、スナップショットの累積ファクトテーブルを使用して、問題のステータスの変化を経時的に追跡するのに適しています。

例として、これがITの問題/バグ/拡張管理システムであり、「作成済み」、「進行中」、「解決済み」の3つのステータスしかない問題があるとします。

問題のファクトテーブルは次のようになります。

ID Number (Degenerate Dimension)
Issue description (Degenerate dimension. You can also create a 1-1 table for these if it's not often used in reporting)
Type ID (bug/enhancement/etc, this is a dimension key)
Assigned Developer ID (Dimension key)
Current Status ID (Status dimension key)
Date Created (DATE dimension)
Created Flag (1 = created, 0 = otherwise)
Date In Progress (DATE dimension)
In Progress Flag (1 = created, 0 = otherwise)
Date Resolved (DATE dimension)
Resolved Flag (1 = created, 0 = otherwise)
Created Datetime (measure)
InProgress Datetime (measure)
Resolved Datetime (measure)
Worktime Interval (measure)
Cost (measure)

この表の詳細は、発行ID番号ごとに1行です。

このタイプのファクトテーブルでは、ソースシステムが問題を変更するたびに同じ行を更新します。各ステータスタイプのフィールドと、「作成されたステータスと解決されたステータスの間の時間」などのメトリックを計算できるようにする日時レコードを作成する方法に注意してください。さらに、開発者が修正に費やした「時間」などの「実際の」作業時間を保存できるように、間隔フィールドを追加しました。これは簡単に整数になる可能性があります。

このテーブルは、問題に関する質問に答えることができ、「解決に1週間以上かかった問題の数」などを示すロールアップを提供します。

于 2012-09-04T15:27:06.977 に答える