ファクトテーブルまたはディメンション/属性値のメジャーとしてのブール値
私のファクトテーブルは、だれが、何を、いつ、という典型的な側面を持つ苦情で構成されています。一定期間内に対応することを目標としています。
苦情がその期間内に応答したかどうかをモデル化するのに最適な方法がわかりません。
ターゲット値と結果の両方を、結果としてメジャーとして整数としてファクトテーブルに格納できます。または、これをメジャーとして表す代わりに、yes/noの値を持つディメンションを使用して、計算されたメジャーをキューブで使用することもできます。または、両方を組み合わせて使用することもできます。
上記の方法で事実をモデル化する長所、短所、および落とし穴はありますか？
このファクトテーブルは、苦情の総数、時間内に対応した苦情の数、時間内に対応した割合、および時間内に対応しなかった個別の苦情を特定するために使用されると予想しています。
これは、将来の要件の変更をサポートする、柔軟な保存方法です。
- Dim_complaint_typeなどのディメンションにターゲットを格納します。そうすれば、将来的にさまざまなタイプの苦情が発生した場合に、たとえば請求、技術、... –それらはそれぞれ分類され、異なるターゲットを持つことができます。ターゲット属性に緩やかに変化するディメンションタイプ2を適用することにより、過去の苦情の結果を変更せずに、ターゲットをある年から別の年に変更することもできます。また、1次元のターゲットを変更して「what-if」分析を実行し、時間どおりにどれだけ多いか少ないかを確認することもできます。
- 応答時間を、経過時間（整数）またはコメントで提案されている登録日と終了日としてファクトテーブルに格納します。私の好みは、
registration_date - closing_dateである計算された列の経過時間を伴う登録日と終了日です。
結果として、フラグ（はい/いいえ）としてではなく、数値として保存します。列on_timeを呼び出して、ターゲットを満たす苦情ごとに1を入力すると、その列で簡単にSUMを実行して、期間中の合計のオンタイム苦情を確認できます。
結果を得るには3つの方法があります。
- それを保存するのではなく、
fact_complaint.elapsed_timeがdim_complaint_type.target以下であるかどうかを確認するためにどこでも同じ数式を使用して、レポートで即座に計算します。別の人が別の式を使用すると危険な場合があります。メタデータレイヤーを備えたツール（OBIEE、SAP BOなど）がある場合は、その結果のメジャーをすべてに対して一度定義できます。 - Fact_complaintとdim_complaint_typeを結合するビューを作成し、その結果メジャーを選択リストに追加します。すべてに対して一度定義されます。ただし、一部のレポートツールはテーブルやビューと同じように機能しない可能性があるため、このアプローチには注意する必要があります。データベースオプティマイザーも、すべての魔法を同じ方法で実行できない場合があります。
- 実際にファクトテーブルに格納します（つまり、ETL時に計算します）。これはおそらくパフォーマンスの面で最良のアプローチです。ただし、過去の苦情の対象を変更した場合は、その列を更新する必要があります。