Question

只是想知道代理键是否需要在自然键上明确排序？当使用截断和重载时，是否始终需要使用自然键绑定相同的代理键？或者没关系，我有一些使用delta加载的大表，基本上只是插入和更新。我不想订购数据以确保代理密钥和自然密钥总是绑定，如果他们不需要？这不是为什么他们是无意义的钥匙？

Answer 1

代理键的实际数值与记录中的自然键或其他字段无关。也就是说，一旦您为记录分配代理键，您就不应该破坏该链接或冒险在您的数据中留下孤立的事实记录。

你可以在一个缓慢变化的维度表中清楚地看到这一点，该表有一些自然键的多个版本。

sur_key nat_key description version valid_from valid_through 1 105 UK Office 1 1900-01-01 2017-02-16 2 108 FR Office 1 1900-01-01 2099-12-31 3 109 NL Office 1 1900-01-01 2099-12-31 4 105 UK/IRL Office 2 2017-02-16 2099-12-31 5 102 DK Office 1 1900-01-01 2099-12-31

正如您所看到的，新版本的自然键105只能获得下一个代理键并且旧记录保持不变。迟到的钥匙102也只是获得下一个钥匙。

任何自然键的排序只发生在该列的索引中，而不是在表本身中。

Answer 2

代理键和自然键一般不应该有任何直接关系。尝试保持它们对齐将是一个维护的噩梦，并且当新数据被添加时，您将不断地重新分配密钥。

在截断并重新加载密钥表之后，您的暗淡记录可能会以不同的SK结束，还需要更新/重新加载您的事实记录。

如果这是重复出现的情况，您可以在事实表中包含自然键。它确实需要更多空间，但它使重新加载和故障排除更容易。

Answer 3

Inmon将数据仓库描述为面向主题，集成，时变和非易失数据集合。

对于集成的工具，我们必须理解代理键的概念。

即。我们必须为一组零售店创建DWH，因此我们必须在不同的商店中提取数据项详细信息数据。

   Shope 1 

   Item 
   Itemid  Name 
    1      Tea
    2      suger

    Sales
    orderid       Itemid   tola

    1               1      100
    2               1      100
    3               2      300

    Shope 2 

    Item 
   Itemid  Name 
    1      cofee
    2      tea

    Sales
    orderid       Itemid   tola

    1               1      100
    2               1      100
    3               2      300

当我们在仓库中使用自然键（itemid）将数据拉到shope时，没有itemid 1可能有不同的项目，现在我们无法通过Itemid识别记录现在我们需要两个字段ItemID和Shope no（自然键） +数据源标识符）。现在想想如果有一个交易数据（销售）被拉动以建立关系，我们必须加入两个列（自然键+数据源标识符），这将降低性能。

第二种情况你必须实施SCD，然后你还需要代理键。

In nut shell surrogate keys is improve performance (read) and helps to implement [SCD][1]

回答问题。

             Just wanted to know whether surrogate keys need to be ordered explicitly on the natural key?   no

使用truncate和reload时，是否始终需要使用自然键绑定相同的代理键？取决于SCD的实施或者没关系，我有一些使用delta加载的大表，基本上只是插入和更新。我不想订购数据以确保代理密钥和自然密钥总是绑定，如果他们不需要？你将无法关联数据这不是为什么他们是无意义的钥匙？读

代理钥匙需要通过自然钥匙订购

3 个答案: