你應該有一個DimContract & FactContract,以及一個DimComplaint & FactComplaint。
DimContract可能只包含ContractID(退化維),但Code也可能屬於此處,因爲它看起來取決於ContractID。 FactContract連接所有描述的合同
- DimContractType維度的屬性,
- DimDate作爲DimDateContractSigned
- DimCustomer?
- DimSalesPerson?
DimComplaint可能由ComplaintID和Code組成。如果網站是自由文本,那麼它也可以包含在這裏,如果用戶從列表中選擇它,它就是事實。 FactComplaint連接所有描述該投訴的尺寸屬性:
- DimComplaint,
- DimContractID,
- DimServiceType,
- DimTitle,
- DimStatus,
- DimDate如DimDateOfComplaint,
- [DimWebsite if appropriate]
在此示例中,由於投訴引用了合同並且合同引用了客戶,因此您可以看到客戶和投訴之間的關係,而無需從FactComplaint直接引用DimCustomer。
這是一個好主意,但我不能做我的數據庫。不僅有2個表,實際上有4個表......:要求,執行,結算...每個合同都有一個或多個價值要求,賬單......合同表與這些表的關係是一對一-許多。 所以我想要合約表將FactTable。 –
你能解釋一下你提到的表格是什麼意思嗎?需要,執行,賬單?從目前爲止你所說的話,我認爲RADO是正確的,契約應該是一個維度。 – Rich
@TrầnĐìnhHưng:我添加了一個鏈接到我的答案,這將有助於您瞭解星型模式設計。很抱歉地告訴你,但你不能隨意指定事實和維度 - 它們的角色是由它們的數據結構定義的。事實表積累交易(在你的情況下,投訴),而維表提供這些交易的上下文(例如客戶,地點,產品等,在你的情況 - 合同)。暗淡表必須具有唯一的鍵,並且必須始終處於關係中的「1」一側,而不是「多」一側。 – RADO