事實表中的物理Pkey

Question

我在接受采訪。 我為他們做了一些代碼，他們很想知道為什么事實表中沒有PKEY，為什么有重復數據。 在我看來，FACT可以保存昏暗的外鍵，並且不需要物理PKEY。 並且在明顯點上，外鍵列將具有重復項。 那是什么目的。 給我展示不同階段的不同事實。 現在，從邏輯上講，某些組合鍵實際上可以構成主表，但是在數據庫中將其作為物理表是一個好方案。

總結我的問題。 1. FACT物理上是否應具有主鍵？ 2.我們可以在fkey列的集合上使用物理PKEY嗎（我不認為ms sql會允許這樣做）？ 3. FACT是否應該僅出於pkey的要求就具有代理密鑰？ 我們可以在日期等其他重要列上訂購嗎？

期待有待對此有所不同的意見。

Answer 1

我要假設，當訪調員詢問事實表的主鍵時，他們在詢問它是否需要代理主鍵（即唯一的數字，通常由序列或自動遞增生成）。

在Kimball方法中，替代主鍵用於維度表中。 除了少數例外，事實表不需要代理主鍵。 事實表具有主鍵，但它是由指向維度的外鍵列的子集組成的組合鍵，這使得唯一標識符適合作為主鍵。 此鍵是物理的，因為您在創建表時定義它，而數據庫通常會為已定義的主鍵建立索引。

這種概括的例外是：

• 有時，業務規則允許使用相同的事實行。 在這種情況下，您需要一個代理密鑰來唯一標識事實記錄。
• 如果您具有代理主鍵，則某些ETL工具的性能會更好，尤其是當您需要ETL更新/插入一行然后刪除先前的事實記錄時，這種情況尤其如此。

在這些情況下，代理主鍵是有益的。 但是，這不是您要暴露給最終用戶的東西，它僅僅是滿足技術需求的一種便利。