Dimensional-Modeling
在 Kimball 的 Dimensional 數據倉庫設計模型的實踐中，查找表（不是維度）是否包含 sid 列？
嘗試為 BI 網頁上的下拉菜單創建一個簡單的查找表。該表包含 2 列，一個鍵和一個描述。
設計此表時，關於維度建模的最佳實踐是什麼？key => number, description => character (column => data type) 是否足夠，或者 key 是否需要是 SID？
想想像“國家”這樣的網頁或網路表單中的下拉菜單。
如果您的自然鍵只能與一個描述相關聯，並且您的查找表僅包含靜態參考數據，那麼我認為不需要代理鍵。
在您給出的範例中，您的下拉列表將包含國家/地區。從我的角度來看，如果維度模型基於星型模式，那麼國家將不會成為一個獨立的維度，而是會成為另一個維度（例如地理或客戶等）的屬性。即使您要添加代理鍵，這也不需要包含代理鍵，因此會浪費時間、精力和儲存空間。
如果您的維度模型基於雪花，或者您的鍵可以與多個描述相關聯（例如，如果描述可以隨時間變化），那麼是的，我會包含一個代理鍵。我不會把它放在參考表上，代理鍵應該屬於擁有數據的維度。