数据仓库--代理键

[转]数据仓库设计——代理键

转载 2015-12-06 12:12:22

标签： it 数据仓库 代理键

       在关系型数据库设计中，代理键是在当资料表中的候选键都不适合当主键时，例如资料太长，或是意义层面太多，就会用一个attribute来当代理主键，此主键可能是用流水号，来代替可辨识唯一值的主键。

       在数据仓库领域有一个概念叫Surrogatekey，中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。

      代理关键字的称呼有surrogatekeys，meaningless keys，integer keys，nonnatural keys，artificialkeys，synthetic keys等。与之相对的自然关键字的称呼有natural keys，samatkeys等。

     在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字（SmartKeys）。数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。

 

使用代理关键字，有很多优点。

 1．使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说，当数据仓库需要对来自多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。

 2．使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键联接的效率也很高。

 3．使用代理关键字可以建立一些不存在的维度记录，例如“不在促销之列”，“日期待定”，“日期不可用”等维度记录。

 4．使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是使用代理关键字。

 

      当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。有关使用代理关键字的维度表和事实表的加载方法在ETLToolkit中有详细的描述。使用代理关键字是一个从长远考虑的策略。

一个实际例子：

1、【问题来源】：http://zhidao.baidu.com/question/101736946.html

2、【问题描述】：​小弟有些不明白数据仓库代理键使用的方法

对于事实表,表a

userid(主)  deptid      pay

1            301         50

2            302         30

3            302         40

4            303         15

维度表,表b

deptid  deptname    groupid    groupname

301        销售一部     1         销售区

302        销售二部     1         销售区

303        市场一部     2         市场区

对于用维度表关联只需要 a.deptid=b.deptid就可以了

但我学习了代理键做缓慢维度变化要在唯度表上建立无意义的排序主键

唯度表,表b

bid(代) deptid    deptname     groupid    groupname

1        301        销售一部     1         销售区

2        302        销售二部     1         销售区

3        303        市场一部     2         市场区

看网上资料是要事实表与唯度表代理键关联,请问这种如何关联?我要事实的举例,不要长篇大论,回答的好我追加.

3、【问题回答】：

我看到你的模型设计实际上没有考虑历史数据。要考虑到历史数据，你的相关表结构需要一些变化。

事实表的结构需要变更为：

statis_monthuserid(主) bid   deptid     pay

200901         1          1   301        50

200901         2          2   302        30

200901         3          2   302        40

200901         4          3   303        15

200901         1          1   301        50

200901         2          4   302        30

200901         3          4   302        40

200901         4          3   303        15

 

我理解代理键实际是反应了仓库中维度表的变更历史。

 

例如，你提到的维度表可能发生如下变化

 

bid(代) deptid deptname   groupid   groupname  状态   最后状态日期

1       301        销售一部    1      销售区   失效  200901

2       302        销售二部    1      销售区   在用  200901

3       303        市场一部    2      市场区   在用  200901

4       302        销售二部    2      市场区   在用  200902

​​

PS:

维度表中的主键通常有两种选择：​

自然键（NaturalKey），它是业务系统中已经存在的，通常是具有一定业务含义的一个字符型的标志符，可以唯一地标志维度表中的每一条记录。比如机构的代码、缩写、时间标签等。

另一种是代理键（SurrogateKey），通常是数据库系统赋予的一个数值，是自增型的，按顺序分配，没有内置含义但也可以唯一地标识一条维度信息。​

项目经验，推荐采用第二种，即代理键。原因如下：​

首先，自然键虽然在逻辑上可以唯一地标识出一条维度信息，但它通常是字符型的，且一般比较长，若用它作为维度表中的主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数往往是巨大的，在多个维度表上重复这样的做法会使事实表由于列宽过于膨胀而导致性能的急剧下降。​

其次，代理键可以作为数据仓库与源系统之间的“缓冲”。自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，比如身份证号码，由最初的15位变成了现在的18位。如果这种主键一旦发生了变化，由于它同时作为事实表中的外键，必然会对事实表产生影响，因为已有的事实记录已经找不到与之匹配的维度记录，这就带来了很大的麻烦。但若采用代理键作为维度表中的主键，就完全可以把这些变化屏蔽在维度表内，不会对事实表产生任何影响（当然这个还要结合缓慢变化维度的处理）。​

最后，从关联效率考虑，数值型的关联要比字符型的关联快很多。