Data-Warehouse
布爾值作為事實表或維度/屬性值中的度量
我的事實表包含典型維度的投訴，包括誰、什麼和何時。我們有一個目標，即投訴應在一定時間內得到答复。
我不確定如何最好地模擬投訴是否在該時間段內得到回應。
我可以將目標值和結果作為整數儲存在事實表中，並將結果作為度量。或者我可以使用一個值為是/否的維度，而不是將其表示為一個度量，然後我可以在我的多維數據集中使用計算的度量。或者我可以使用兩者的組合。
以上述方式對事實進行建模是否有任何優點、缺點和陷阱？
我預計該事實表將用於獲取投訴總數、及時響應的投訴數量、及時響應的百分比以及辨識未及時響應的個人投訴。
這是一種靈活的儲存方式，可以支持未來需求的變化。
- 將目標儲存在像 dim_complaint_type 這樣的維度中。這樣，如果將來您有不同類型的投訴——例如計費、技術等——每一個都可以分類並有不同的目標。通過在目標屬性上應用漸變維度類型 2，您還可以將目標從一年更改為另一年，而不會更改過去投訴的結果。您還可以通過在一維中更改目標來進行“假設”分析，並查看現在準時的更多/更少。
- 將響應時間儲存在事實表中，作為 elapsed_time （整數）或註冊日期和關閉日期，如評論中建議的那樣。我的偏好是 registration_date 和 closing_date ，計算列 elapsed_time 是
registration_date - closing_date.對於結果，我不會將其儲存為標誌（是/否），而是儲存為數字。如果您呼叫該列
on_time並為每個符合目標的投訴添加 1，您可以輕鬆地在該列上求和，以獲得一段時間內的 on_time 投訴總數。我看到了三種獲得結果的方法：
- 不儲存它，而是在您的報告中動態計算它，方法是在各處使用相同的公式來檢查是否
fact_complaint.elapsed_time低於或等於dim_complaint_type.target或不。如果不同的人使用不同的配方，可能會很危險。如果您有一個帶有元數據層的工具（例如 OBIEE、SAP BO、…），您可以一次性定義該結果度量。- 創建一個連接 fact_complaint 和 dim_complaint_type 的視圖，並將該結果度量添加到選擇列表中。它將被定義一次。但是您需要謹慎使用這種方法，因為某些報告工具可能與表格或視圖的行為方式不同。數據庫優化器也可能無法以同樣的方式發揮其所有魔力。
- 實際上將它儲存在您的事實表中（即在 ETL 時間計算它）。就性能而言，這可能是最好的方法。但是，如果您更改某些過去投訴的目標，則需要更新該列。