Data-Warehouse
基於產品類型的產品屬性維度 - 稀疏維度？
我正在為銷售事實創建產品屬性維度。
產品的屬性取決於產品類型。例如： - 類型 = 智能手機。屬性 = 型號、作業系統、大小 - 類型 = 書籍。屬性=作者，標題
這種情況下的尺寸應該是多少？
我應該創建包含所有屬性的維度嗎？在這種情況下，維度內容將是稀疏的，會有很多空值。
|----------------------------------------------------| | DimKey | Type | Model | OS | Size | AUTHOR | TITLE |或者，我應該為每個創建維度嗎？在這種情況下，銷售事實將有許多 FK。
|-------------------------------------------------------------| | FactKey | Quantity | Total | Book_FK | Smartphone_FK | .... |有沒有其他方法可以做到這一點？
我不會為每種產品類型創建單獨的外鍵。這被稱為蜈蚣事實表。
我會考慮為可以在邏輯上分組的產品創建單獨的事實表。即 FactTechnologySales、FactBookSales。然後您將擁有 DimTechnologyProducts 和 DimBooks 維度。這將最小化維度表中的 NULL 欄位。（請注意，我實際上會用 N/A 填充這些 NULL 欄位，而不是讓它們為 NULL）。
如果您只想擁有一個事實表，則創建一個具有產品名稱、產品描述、產品類別、產品類型等屬性的產品維度。其中產品描述是智能手機的型號 + 作業系統 + 尺寸和書籍的作者 + 標題。使用“產品類別”和“類型”欄位創建一個層次結構供使用者向下鑽取。對於不適合描述的任何其他屬性，然後將它們放在垃圾維度中。
如果它那麼稀疏，我首先不會嘗試通過星型模式對其進行建模。
關於建模這樣一個維度的困難，Ben Oastler 的回答是正確的。您要麼擁有大量事實表、大量維度列，要麼將這些屬性中的大部分連接成更簡單的屬性。
然而，正是為了解決這類問題，NoSQL 解決方案才應運而生。如果您的數據不適合表結構，也許您不應該嘗試。
例如，看看 MongoDB。每個文件都是一個產品，只設置實際存在的屬性，並且可以對其進行分層。