DW の累積スナップショット設計を発見しました。
バグトラッカーからのバグ情報を記録する必要があります。バグにはいくつかの情報 (バグ番号、文など) があります。ステータスもあります: 作成済み、キャンセル済み、影響あり、解決済み
バグはすべてのステータスを通過する必要はありません (作成からキャンセル、または作成から影響、解決へと進むことができます...)
これが私の中心的なファクトテーブルです
FT_Bug_Track
idBug int
BugSentence varhchar(100)
作成日DATE
解決日DATE
影響を受ける日付DATE
キャンセル日DATE
FKStatus int
ステータス外部キーは、現在のステータス (作成済み、キャンセル済みなど) を示すディメンションにリンクするだけです。
(もちろん、プロジェクト、クライアント、typeOfBug などの他のディメンションもあります ...)
バグのステータスが変わるたびに、必要に応じて新しい日付を入力し、FKStatus を現在のものに更新します
私の設計は DW と私のシステムにとって適切ですか?
それがあなたの状況に適した設計であるかどうかはわかりません。それは、要件が何であるか、つまりレポートに何を表示できるようにする必要があるかによって異なります。そのため、データがどのように使用され、ユーザーがそこから何を期待しているのかを明確に理解していない場合は、大きな設計上の決定を下す前に、まずそれを行う必要があります。
そうは言っても、スナップショットの蓄積は、製造プロセスやローンの承認など、(比較的) 明確に定義された安定した一連のステップを経る場合に最も効果的です。残念ながら、これはバグトラッカーではめったにありません。ステータスを変更せずに、チケットを別の人に再割り当てできます。それらは再度開かれ、解決プロセス全体を再度実行できます。「開発中」と「テスト中」などの間を「跳ね返る」ことができます。つまり、1 つのチケットの存続期間中にいくつの日付とステータスが必要になるかを事前に知ることはできません (非常に単純なプロセスを使用しない限り)。
私は最近、ヘルプデスクのレポート作成に取り組み、2 つのファクト テーブルを使用するソリューションを考え出しました。最初の行はチケットごとに 1 行あり、現在のステータス (新規、割り当て済み、クローズ済みなど) のみを表示し、「作成済み」と「最終変更済み」のタイムスタンプのみを表示します。2 番目のファクト テーブルには、チケットの変更ごとに 1 つの行があるため、チケットの詳細な履歴にドリルダウンできます。ここで、チケットへの多くの一般的な変更 (コメントの追加など) は実際にはステータスを変更しないことに注意してください。そのため、「変更」とは何かを判断する必要があります。
ETL プロセスは、最初のファクト テーブルでチケット レベルの KPI を計算および維持します。たとえば、チケットがオープンされている (またはオープンであった) 時間、チケットを送信してから最初に割り当てられるまでの時間などです。レポート ユーザー (マネージャーなど) は通常、特定の 2 つのイベント間の期間に関心があり、繰り返しまたは周期的なプロセスを処理するのは特に簡単ではありません。このため、メインの (集計) ファクト テーブルを使用してほとんどのレポートを生成しようとし、2 番目のテーブルは主にインタラクティブな分析のために残しますが、すべてはデータから何を取得したいかによって異なります。
これがあなたの質問に答えていなくても、いくつかのアイデアを与えてくれることを願っています.