我參與創建利用Kimball星型模式方法學的報告軟件。整個團隊（包括我）都沒有使用這項技術，所以我們是這方面的新手。
到目前爲止，還有一些維度和事實表或系統。例如：
- DIM_Customer（客戶維度表）
- DIM_BusinessUnit（業務單位維度表）
- FT_Transaction（事實表，每筆交易的粒度）
- FT_Customer（客戶，客戶ID和事實表關於日期是在複合PK）
事實表組織
這是FT_Customer的當前結構：
- CUSTOMER_ID＃（客戶ID，複合PK的一部分）
- as_on_date＃（觀察日，複合PK的一部分）
- waic（KPI）
- 笏（KPI）
- waddl（KPI）
- wadtp（KPI）
- aging_bucket_current（KPI）
- aging_bucket_1_to_10（KPI）
- aging_bucket_11_to_25（KPI）
- ... ...
領域wa wat，wat，waddl和wadtp與延遲交易支付有關。這些字段通過根據customer_id和as_on_date分組的FT_Transaction表進行聚合查詢來計算。
字段aging_bucket_current，aging_bucket_1_to_10和aging_bucket_11_to_25包含按支付延遲分類的交易數量。例如，aging_bucket_current包含按時支付的交易數量，aging_bucket_1_to_10包含以1到10天的延遲支付的交易數量...
此結構用於從PHP Web應用程序以及Cognos studio生成報告。我們討論了重構FT_Customer表以便使它更適用於像Cognos這樣的外部系統。
新提出FT_Customer的結構：
- CUSTOMER_ID＃（客戶ID，複合PK的一部分）
- as_on_date＃（觀察日，複合PK的一部分）
- kpi_id＃（KPI的ID，外鍵點DIM_KPI維度表複合PK的，一部分）
- kpi_value（價值KPI）
- ......
對於這個建議，我們將有更多的維度表DIM_KPI：
- kpi_id＃
- 標題
Thi s表將包含所有KPI（wat，waic，waddl，老化桶......）。
FT_Customer的第二個結構顯然比當前結構具有更多的行。
FT_Customer的哪種結構更通用？
把兩個結構都保存在不同的表中是可以接受的嗎？這顯然會給ETL層帶來額外的負擔，因爲有些工作將會進行兩次，但另一方面，這將更容易地生成各種報告。
在此先感謝suggenstions。